Forgot your password?
typodupeerror

Comment: This is a flaw in Westell UltraLine Series3 Router (Score 1) 102

by tyrr (#33786038) Attached to: Geolocation XSS Tracker Proof of Concept
The XSS posted works only on a small class of SOHO routers, e.g. Westell UltraLine Series3 Routers.
If you have anything more sophisticated then a Westell UltraLine Series3 router, you are not affected.
The XSS uses the factory default router IP 192.168.1.1 to send HTTP requests to your router.

Comment: I am fine with being called IT (Score 1) 736

by tyrr (#30262580) Attached to: Do You Hate Being Called an "IT Guy?"
I work in the Engineering Department. Engineering is indeed a very important aspect of my work. However, Information is even more important part of my responsibilities.
I prefer to be called Information Technology because that is what my work ultimately affects. Information acquisition, refinement, verification, processing, analysis, synthesis, storage, distribution, and protection are my specialties. In a way, that makes me the most knowledgeable person in the company.
I am a Druker's "knowledge worker".

Comment: Re:Everything for the database (Score 2, Insightful) 146

by tyrr (#29390447) Attached to: Oracle To Increase Investment In SPARC and Solaris

People don't complain when Cisco, Juniper, etc integrate their routing/switching/firewall features with ASICs.
Why should databases be different?
Given the hardware prices and wide interest in FIPS-type security requirements, Oracle might as well be selling appliances. It will come to this sooner or later.

Comment: Re:Android = no native code support (Score 1) 263

by tyrr (#28382707) Attached to: Nvidia Lauds Windows CE Over Android For Smartbooks

Most of these discussions/arguments about Java are strictly concerning performance, like whether or not Java is bloated and slow. Your post there is one of the first I've seen that neatly answers the question of "why Java?" If it is as you say, then that's a highly desirable feature. That's especially when you consider the volume of personal information that's usually contained on a mobile phone, which I'd imagine would make it an attractive target for malware.

For better or worth, software development is nothing like video games. Performance, the topic of obsession for video gamers, is oftentimes an afterthought in industrial software development. Security, reliability, maintainability, computability, clarity receive higher priority almost each and every time. In order to understand this, of course, you have to spend a few too many years in software development. The truth about performance is rarely taught in CS university course, and almost never understood by CS students. I too was a fresh CS grad over a decade ago (I actually remember the time when Slashdot was popular) and despised, if not hated, Java. I adored C, optimized parts of the code in assembly, and though I knew everything there is to know. Boy was I silly. I was forced by my employer to deal with Java parts in a huge mixed codebase in 2000. I accepted Java in 2003 when it finally started producing decent benchmarks on the brand new Linux test equipment. Since then, I worked on many diverse problems, broadened my software architecture experience, and came to appreciate Java's design. I don't think I can design a better platform myself. I know that James Gosling is a freaking generous because I remember when I though he was a fool. Software design should never focus on fixed performance cost factors. Moore's law will marginalize fixed performance factors in a matter of years no matter how high in absolute value these fixed factors are.

But don't take my word for it. Listen to my elder colleague Charles E. Leiserson from MIT - Why study algorithms and performance?

I don't know much about Java but this got me curious. What does Java offer here that would be difficult (or impractical/impossible) to achieve with using syscall restrictions and other devices to sandbox the apps? With virtual memory and appropriate syscall restrictions that sounds like it should work too, and would make it easier to run native code, yet I don't hear of devices that use such an approach. Is it that both methods are equally viable, only with Java someone has already created an implementation that is useful for mobile phones so why reinvent the wheel? Or is Java's approach inherently superior in some way?

Unfortunately, writing a program that would validate system calls is much much easier said than done. It takes no time what so ever to say it. If you actually start writing a program like that, you will quickly realized that this will be The most complicated problem of your life. Take a look at the NSA SELinux codebase. SELinux actually implements an extremely limited functionality to validate system calls. SELinux configuration cannot be controlled from the user space, so it is useless in any environment where you actually want to leave some security decisions to users. Also remember, if you create a workaround to give users some control over SELinux configuration, nothing will stop a malicious program run by a user from using the workaround you created without the user's knowledge. You need at least 3-tier architecture to implement a usable security. Moreover, you will have to analyze sequences of system calls in bundles and not just do an analysis call by call. Solving problem after problem, you will end up writing a virtual machine in pretty much the same way it is written for Java. It took more than 10 years for Java developers to implement their virtual machine solution - they started around 1992 and the most functional J2SE 1.4 appeared in 2002. It makes no sense what so ever to write a virtual machine yourself.

MySpace generation needs mobile communication devices to be promiscuous with. Security is one of the top design priorities, and Google just hit a jackpot with Android.

Comment: Re:Android = no native code support (Score 1) 263

by tyrr (#28380283) Attached to: Nvidia Lauds Windows CE Over Android For Smartbooks

There is nothing simple about solving the system call validation problem. You actually end up writing a VM.

You are also forgetting about the problem of arbitrary memory pointers. You don't have to break into the privileged kernel mode in order to break security. All you have to do is to read or write what you are not allowed to access.

Comment: Re:Android = no native code support (Score 1) 263

by tyrr (#28380065) Attached to: Nvidia Lauds Windows CE Over Android For Smartbooks

Native code is not officially supported. The Android-SDK gave me Java last time I tried.

Crosscompile your application for ARM and push it on your Android phone with adb.

The trick of native code is that you do not need to buy expensive hardware to run you application at decent speed. You can run your server even on ARM Cortex while Java needs some expensive hardware to be even considered. Cost saving, green technology, etc. that is what native code enables. While Java is designed to sell pricey hardware from day one.

The trick with mobile devices is that users want to run hundreds of thousands of untrusted programs from application markets. Native code leads to viruses, trojan horses, keyloggers and all kinds of nasty things. Users have to have a protection mechanism. Java with its multilayer security is perfect for mobile applications.

If you are talking about servers, I have a newsflash for you. The majority of servers hardly use even 50% of their processing capacity on average. Java overhead at this stage of CPU development is negligible. Green movement will benefit more from saving the resources spent on development and maintenance of native code.

Comment: Re:Android = no native code support (Score 1) 263

by tyrr (#28379019) Attached to: Nvidia Lauds Windows CE Over Android For Smartbooks

You are talking pure nonsense.
First, for many devices it is not about speed, it is about security. Java provides a very robust security framework to run untrusted code. If you were to make a similar security framework for C/C++, you would end up with Java.
Second, if Java runs too slow for you - buy a better CPU.
Third, I doubt you realize how many productions systems are running Java. My department alone is running a multi-million dollar platform all on Java.
Last, you actually can run C/C++ code on Android. You can run ARM assembly, C-Sharp, and Python too. But don't tell anyone.

Comment: More business for ATI (Score 1, Troll) 263

by tyrr (#28378579) Attached to: Nvidia Lauds Windows CE Over Android For Smartbooks

If NVidia does not want a piece of Android business, it is NVidia's loss.
And AMD/ATI gain.
My money is on the Linux community figuring out how to incorporate NVidia support into Android with or without NVidia's corporate blessing. Heck, a few of NVidia engineers belong to Linux community too.

Comment: Re:Chuck Connel does not understand Simon's work (Score 1) 306

by tyrr (#28236587) Attached to: How Software Engineering Differs From Computer Science
I agree, Simon's description of human decision making is just a good lens through which to explain some facet of human behavior. But mathematics is too just a good lens through which to explain some facets of objects overall and computer science in particular!

In no way is mathematics absolute - especially mathematics in computer science. In many ways, mathematics is just a continent way of thinking about things. Ocean waves do not really follow Fibonacci sequence. It is just convenient for us to think they do. Nature in general knows nothing about our mathematical tricks, so in a way mathematics exists only in our heads. Our brain attempts to recognize and match sequences often times fooling itself along the way. Take, for example, the sound a mechanical clock makes. Your brain makes you to believe that you are hearing ticks and tacks, even though the clock makes only one pitch sound.

With the first assumption introduced, or with the first approximation made, the strict logic breaks in every mathematical line of reasoning. Yes, you can have a very nice and straightforward proof that the sum of angles in a triangle is pi, but you had to assume that the parallel lines never cross. The assumption you made, however, is not at all accurate. It is just too convenient to think that the parallel lines never cross. Some people believe that the parallel lines never cross, others believe in god. Both fool themselves. Remove the erroneous assumption about parallel lines and all mathematical proofs in Euclidean geometry people worked hard to create become a worthless illusion. The fact that this illusion was "good enough" to make common engineering tasks work does not mean that this illusion is true, much less absolute. Mathematics actually has a name for such illusions - models. Models are whatever your brain makes them be.

Who can actually trust "mathematical" proofs used in computer science?! Every algorithm analysis has to be reduced to asymptotic approximations right away because it is way to hard and inconvenient to make precise calculations. Many algorithms have to be analyzed in terms of expectation (making a hidden assumption along the way that the probability distributions are normal). With so many assumptions and approximations how can anyone actually believe that the result obtained is absolute? In a basic case, you read an analysis that tells you that quicksort runs in NlogN order time. Is this analysis in any way absolute? Not really (quicksort may as well run in N^2 order time). Convenient? Maybe. This analysis is certainly trying to convince you to believe in something that may or may not be true.

Just because algorithm analysis uses mathematical symbols does not mean it is more reliable that Simon's line of reasoning. Very recently, many financial institutions believed that sophisticated mathematical formulas are absolute. They were convinced that they had it all figured out. Look where it got them.

Almost anything derogatory you could say about today's software design would be accurate. -- K.E. Iverson

Working...