This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Messages - calcforth
46
« on: November 22, 2010, 04:27:49 am »
This is for the FIRST robotics competition.
I was informed of two choices - Java or C (maybe C++? One of the C's) All things being equal C++ will be better choice. Of course things rarely are equal  I have no experience in Java - but the team (which I just joined this year) is reusing the bulk of the program from last year, which was written in Java (because one of the seniors last year knew Java). Well, if they already have something working then it's not a good idea to start total rewrite in different language. It's rarely a good idea in general, but especially when you are competing with someone. I would love to use Python, but I have no idea how to get a python environment working. Python is worse then Java in many aspects. It very nice to program, but quite slow. The one thing which is fast in Python and slow in Java is C/C++ interface. I had to go to a presentation this Saturday just to learn how to get Java/C++ running. My advice WRT to Java/C++ integration: don't try to push small pieces of task to C/C++. JNI is very slow by design: because it must do lot's of thing WRT GC (objects must be compacted and frozen, etc), so while C/C++ procedure may be faster then Java the switch from C/C++ and back will often eat all adavantages of such hybrid approach. I don't care much about the detriments of Java, especially because I don't have any viable alternative to present and because I'm not experienced+eloquent enough to communicate the difference well. You must keep them in mind if you want to write competive Java program. It's very easy to lose track of things in Java - and this leads to tons of unneeded work in runtime. It's possible to write good program in Java, but sadly Java encourages mindless programming so you must resist. Also, don't forget about the biggest advantage of Java: powerful IDEs. Two top free ones are Eclipse and NetBeans. Two top paid ones are IntelliJ (it has free community version and classrom license) and JBuilder (very powerful but also very expensive). My advice: don't try to program Java without help of IDE (VIM and emacs with bunch of addons can be considered an IDE but only make sense if you were avid VIM/emacs users before trying Java). This is greatest strength of Java and a reason for it's continuing existence. Also: ask around for what other members of team are using. Often it's easier to use the same IDE as others are using rather then using superior (in your opinion) IDE which does not play well with changes made by others. And last but not least: learn some version control system if you still have time! My preference will be Git - but only if you are using Eclipse or IntelliJ: NetBeans and JBuilder have unofficial modules (development of official NetBeans plugin started just recently) thus intergration is not as good. But again: talk with other members of a team.
47
« on: November 21, 2010, 10:52:58 pm »
Java can be programmed for mostly anything, as of recently. You have very peculiar definition of recently. Java Card was introduced 15 years ago. if there's one thing java's good at, it's portability its ability for old versions of programs to still work today. Not true as well. C beats Java by wide margin: lots of programs from 1970th can be compiled and run today. And if we are talking about unmodified code, then the answer is two words: Java ME. if you try to do something out-of-normalcy in the language, you'll get hit for it because java is all about standards. Yup. Really, the only advantage of Java is the fact that muddleheads can write half-working code. If you give some specs and Java IDE to bunch of monkeys then there are some non-zero probability that they'll produce some kind of more-or-less working program. With C++, Haskell or even Pything this probablity is very close to zero so you are constantly faced with the dilema: what to do with people who are ruining the projects but can not be fired because of labour legislation?
48
« on: November 21, 2010, 09:13:44 pm »
I recently joined a robotics club at school, and joined the programming team. However, as it turns out, the robot will NOT be programmed with either Axe or TI-Basic (blasphemy!) and will be programmed in Java instead. Yup. Java is popular so people are using it where it does not belong. What are some common 'gotchas' that might trip me up, especially given that I'm used to coding calculators? Surprisingly enough the biggest gotcha is not the Java - it's the culture around Java. It's decidely unhealthy. All books and courses will try to teach you "Java way": where extensibility and testability is paramount and efficiency is secondary concern. This works fine when you develop some complex and slow system (where the ability to create something working is often more important then efficiency of the result: if the thing does not work at all then it does not matter if it's efficient or not), but for simple things "Java way" often produces horrible results. If the task is simple and does not need extensibility then often it's better to just use array or matrix (as if you worked with Basic) rather then hierarchy of objects (as "true Java way" teaches). Why is that? The problem here is dynamic memory and garbage collection: the more objects you create the more unpredictable the timing becomes - and this is NOT a good thing for robotics. Books will say that lots of temporary objects is not a problem: GC is sophisticated enough and will take care of everything... and this is just not true. It does not matter how big and elaborate your collection of objects becomes as long as it's essentially static (so you don't allocate anything on constant basis and so garbage collector is not forced to clean up everything constantly), but when you start creating myriads of new objects in response to exteranl stimulus - you are in trouble. I've seen the case where simple logging spent more resources then actual work in automation system because it used standard library - and something like printf("Parameter f is %3.0lg",f); generates dozens of objects (starting from the call itself: it actually creates anonymous array). Jerky reaction become smooth and fast when said logging was replaced with home-brewn procedures which used pre-allocated arrays.
49
« on: November 20, 2010, 12:29:38 am »
As for microUSB, I'm not sure I want to write KnightOS variant for a microUSB calculator. Not a lot of people have microUSB cables, and signifigantly less have male microUSB<->female USB cables, and I feel that it would provide a bad user experience and reflect poorly on my skills as an OS developer. Well, the "microUSB revolution" started at the beginning of the year and average replacement time is 18 months (somewhat longer in US because if 2-year contract). By the time we can realistically expect something mass-produced they will be more common then miniUSB cables. That's the point. What you designing today you'll have on sale few years down the road - this rule it true for both large companies and hobbyst projects alike. That's why Pandora started taking pre-orders on September 30, 2008 and shipped on May 21, 2010. Note: by the middle of 2008 they had not only bunch of specs, but some actual prototypes - it took this long to actually mass-produce things! OTcalc is slightly less ambitious, but the difference is not material.
50
« on: November 19, 2010, 09:04:10 pm »
I think it was due to lack of MicroUSB support, but OTCalc project kinda died now that everyone is busy with school and things probably evolved a bit. I could be wrong about the reason why it was not included, but if I remember, there were many people against the idea of using MicroUSB. Well, the main reason was probably the fact that MicroUSB cables are so hard to find. Well, situation is different now - and it'll be even more different two years from now. We have to keep in mind that rarer usually means more expensive, and outside United States usually means even more expensive, because companies in USA thinks the rest of the world doesn't exist. Well, the Mini-A to Mini-B is not all that easy to find either. And prices are quite comparable. EDIT: Poll topic: http://ourl.ca/6716
(Note, this discussion occured almost 6 months ago) I see... Well, the hardware projects are much slower then software. Typical time from the idea to implementation is 3-4 years - if anything is produced at all. Perhaps closer to the release it'll be more clear if miniUSB is still viable choice. Well, I think we like to stick to old habits for one thing and it doesn't make much difference from what I can see. The difference is literally 2 times. Mini USB is certified for 5000 cycles of insertion and removal, microUSB is certified for 10'000. And this is not just numbers: microUSB is really more robust (that's why phone manufacturers chosen it in first place).
51
« on: November 19, 2010, 08:36:42 pm »
USB poll: This was also another interesting poll. Cemetech was pretty sleepy when this was posted, since there was only one vote (out of all the options, just one vote - what's up with that, Cemetech?). It basically asks "How do you want to connect your calc to the computer?" Some debates occurred with this one, but the final decision? The verdict is mini USB. Well, I'm new here but can anyone explain why the most logical choice was not even included in pool? I mean micro USB, of course. You'll probably ask: why do I think the only choice is the choice which is not even known to many? Simple: mobiles. If history is any indication we'll not see the finished product all that soon - and mobiles are switching to microUSB. The change happened recently and suddenly - but if you'll check new models... the change actually happened (I was sceptic at first too). All new mobiles come with microUSB. Samsung and Nokia, Motorola and HTC, LG and ZTE... everyone (except Apple) are supporting microUSB nowadays. And if the connector will me Micro-AB then you can connect two calcs using this adapter, too...
52
« on: November 19, 2010, 05:34:56 am »
By the way I wish in Russia they were more strict on spambot softwares so people could register on forums like here without getting flagged as spambot. I think half of Russia is banned from almost every forum on the Internet, same for India and Phillipines. Yes, there are lots of spam domains registered in .ru, but as for spambot software... if you actually will check the facts you'll see that Russia is #4 while #1 is US, #2 is Netherlands and #3 is India. As for domains... the most popular webmail providers (ya.ru/yandex.ru, mail.ru/inbox.ru/bk.ru/list.ru, rambler.ru/lenta.ru/ru.ru/r0.ru) are actually pretty good with spam filtering/prevention: I never had trouble using @ya.ru for registration before. Even on sites where hotmail is forbidden  . And even with recent surge of spammy domains in .ru they are still not managed to reach the top position: this place is reserved for .com domains ...
53
« on: November 17, 2010, 07:08:34 pm »
What's the difference between chosen prefix and second preimage collisions? They describe different sharacterists of attack: 1. Collision attack - you want to find two messages with the same signature. 2. Preimage attack - you want to forge signatore on the document. 2a. First preimage attack - you only have a signature. 2b. Second preimage attack - you have an original document as well. 3. Chosen prefix collision attack - collision attack where you want to have valid document (you dictate what you put in document and pad it with some "garbage" to alter signature) 4. Chosen prefix preimage attack (first or second) - the same as with collision attack: you want not random document with given signature but proper document with given signature. They actually created different valid PDF files which had the same MD5SUM yet different predictions for the outcome of the 2008 US Presidential elections :-) See here. As for preimage attacks - they are much harder and there are trouble with a simple preimage attacks, let alone collision prefix ones... In RSA encryption. I have heard of certain implementations that used a not so pseudo random number generator to generate primes, thus if one knows how were generated the random primes we could guess "some" (still a lot) of the primes with an certain size (around 400 to 600 bits) and with naive trial division factor it. I doubt we know how TI generated the primes.
And I have heard of a case where they cracked RSA with 1024 bits secret key this way. (don't ask me from where) You mean Side-Channel Attack? This is a joke: they basicaly need to make random generator so non-random to show feasibility that it's pointless. In partucular it was never shown with normal multi-tasking OS: all demos included two programs run on bare metal with special scheduler. Otherwise noise from scheduler kills the side channel quite efficently. And again: it only works if you can put trojan program on the system which genrates primes - I very much doubt we'll be able to do that. If we're lucky, TI took the easy way out and used a simple deterministic algorithm, assuming that no one would know what their algorithm was. Well, stuff happens but I don't think they used some obsolete Debian installation to generate these numbers.
54
« on: November 17, 2010, 06:29:09 pm »
Most GBA graphics are already 4-bit. The actual colors are looked up from a palette. And I'm not sure how exactly you would locate the graphics data in a ROM automatically, anyway. Also, there are not "graphics routines", there is graphics hardware. You don't need to locate graphics data in a ROM, you only need to block access to HW and emulate it in signal handler. Should be simple to do if Nspire's CPU includes proper MMU. The only question is if it'll be fast enough: context switch is slow business and Nspire is only 10 times faster then GBA... In other words, before we get a calc powerful enough to run a GBA emu at full speed, emulating all effects, it may take years... It's not a question of power: Nspire is more then capable enough. It's question of doing the actual work. Compare XBox (original, not XBox360) emulation with PS2 emulation. It's actually harder to emulate PS2 - but people want it so it works (not perfectly, but compatibility was over 50% two years ago, by now I think it's about 80-90%) while XBox... well, you can run one or two games - and that's all. So ironically enough while I agree that "it may take years" I don't agree that we need new hardware: it'll take years, but the end result will probably be GBA emulator for Nspire, not for some exotic new platform.
55
« on: November 16, 2010, 05:08:25 pm »
Well, PRIZM looks like a toy right now. CASIO does not even say what CPU is there! While screen certainly looks more pleasing then NSpire the software side is superweak. As for "someone will attempt to jailbreak it"... well, PS3 jailbreak took almost four years while Wii was broken in days so it's hard to predict the outcome in advance. We'll see, I guess.
56
« on: November 15, 2010, 07:40:02 pm »
Um i can't do pics because i don't have a method of doing that, unless you would like a really rough sketch done by me, ummmm, lets see Gateway, made in 1996, no idea bout much else at the moment Does it have a CD? If the HDD can be detected then you anways grab CloneZilla, USB HDD and make a backup. To everything else, I got on the phone with 3 people i know who have a lot of experience with computers when this happened, two of them thought the cable to the hard drive was loose, until after i checked it, the other one had no idea. It's quite hard to determine what happened over phone. If the HDD is dying then the first priority is probably to salvage what can be salvaged. Here is decent article on subject.
57
« on: November 15, 2010, 06:03:44 pm »
However, if we could generate an OS with the same Hash as the current OS (a collision), then we could install that OS and the boot code wouldn't realize it. The problem is that any collision is likely to be complete gibberish codewise. No, no - this is not how it works. For MD5 there are so-called "chosen-prefix collisions": files with predermined content and only few bytes of garbage at the end. But still both files are produced by "Alice" - and it does not help us any. And for second preimage attack (this is what we need)... it's not realy practical even for MD4, let alone MD5... and SHA256 is much harder then these! Only proprietary "tip-sikrit" algorythms (like GSM's A5/X) are easily exploited... but it looks like industry finally learned to use public well-test cryptoalgorithms. So instead of direct attack we are left only with possible bugs in OS... but it sure is a big attack vector still
58
« on: November 15, 2010, 05:07:50 pm »
How the collision attack will help us?
Because they let you use your own file instead of the original message without changing the hash.
How? I think you are confusing collision attack and second preimage attack. Collision attack: Alice sends message A to Bob and when Bobs does as it says Alice shows another message B (with the same hash!) in court and says: sorry, this is what I meant, blame Bob for his poor judgment. Second preimage attack: Alice sends message A to Bob but Bob replaces it without another message B and when Alice complains shows that other message (with the same hash!) in court and says: sorry, this is what I've got. Nleash developers play Bob here, not Alice! As I said, it would only allow the theoretical possibility of installing an OS. In practice, it would be next to useless. What use will it have? Even theortical? The boot2 hash one particular hash and this is the only hash we know how to present to boot1. We can not change it thus we can not use collision attack. It's as simple as that.
59
« on: November 15, 2010, 04:35:54 pm »
So....it basically does all the work for you? Yep - and that is the problem. Compiler writes the program for you so often you have only very vague idea about what the program actually does. Worse: sometimes your ideas and compiler ideas differ - and while Haskel gurantees that the produced result will be correct it does not guarantee that the algorithm implemented will be equal to your imagination (because it has no idea about your thought process, you know). The end result is two-step: First step: Euphoria. You write 1'000 lines of code, it works (and does the computations which require 10'000 lines of code in more traditional language), everyone is happy. Second step: Disillusionment. You change some small definition... and everything blows up: instead of producing the result in seconds and using 100MB of RAM (where traditional language will use 10MB) it chews 10GB or RAM and works for a few hours. At this stage you have three choices: 1. Spend few weeks trying to pull the execution model from haskel compiler (to compare it with the model produced by your imagination). 2. Spend month or two rewriting everything in C++ or Java (where you actually control the execution). 3. Give up and just wait till the program will produce something (quite acceptable approach if you only need to run the program once or twice). Haskell is quite nice for prototyping, but to write robust production systems using it you need years of practice. Few people reach this stage (I'm not among them).
60
« on: November 15, 2010, 04:07:53 pm »
However, if (and this is a big if) someone discovered a way to reliably make collisions in SHA-256, then we could conceivably launch a successful birthday attack in reasonable time using Chabaud-Joux techniques (basically testing weak versions of the hash until you have an algorithm that can short circuit the real one) that would theoretically allow us to install another OS. How the collision attack will help us? I can imagine just one scenario: if we'll have friend at TI who will produce two images (one legitimate update and one with non-checking boot2, for example) and will submit the legitimate update using education.ti.com ... But it's probably will be easier for him to just sign non-checking boot2 directly? What we need is called second preimage attack - and it's quite different kettle of fish! I'd like to know, how much work is it brute forcing a collision say, compared to factoring a 512 bit key? They are lightyears apart. Facts: 1. MD4 was perceived weak 20 years ago, was replaced with MD4 in 1992 and broken in 1995 (few seconds on typical computer). 1. MD5 was perceived weak 15 years ago, was replaced with SHA1 in early 2000th and finally "totally broken" in 2009 (few seconds on typical computer). 2. SHA1 was perceived weak 5 years ago, was replaced with SHA-256 closer to 2010 - still unbroken. Given these facts and the claims about "utter failure" of MD4, MD5 and SHA1 you should expect that second preimage attack is now easy too, right? Wrong: only MD4 is "kinda broken" (can be theoretically broken using million computers and about thousand years... hundred years if you are lucky). Also, I found this: http://eprint.iacr.org/2004/304.pdf, which has an algorithm to reduce the number of steps before a collision occurs. This is good algorythm, but it does not buy us much: successor to Deep Thought is still not powerful enough to solve this problem... and sadly, it's already busy trying to solve another problem. I'm pretty sure cryptographers will eventually solve this problem (I mean: they already can break MD4... kinda), but I doubt it's good idea to bet everything on this outcome. P.S. Collision attack has it's uses - but sadly they lie very far from the need to sign Nspire ROM. Better to try to find some kind of programming error... at least for now.
|
Show Posts