My best friend in HS happened to be a genius on paper. Got straight A's freshman and sophomore year, ended up doing less well junior and senior year, and, when he got to college, failed out. He now parks cars in a garage. I don't really care for IQ levels, I think they're mostly meaningless.
It's easy : chromium (http://www.chromium.org/) is the open source project. It's licence is open source and can be found at http://src.chromium.org/viewvc/chrome/trunk/src/LICENSE?revi... it looks like a "BSD with attribution" licence.
Chrome (google.com/chrome) is the "closed-source" distribution to loads of platforms (includes a few closed source components. E.g. it can play .mp3 files). It's got a standard closed source licence.
There are other distributions, for example "fedora" chromium, that doesn't have any codec support. There are versions that are not release-engineered (ie. nightly builds, but still released by some distro), ...
I can't speak to frats or Harvard, but I can speak of personal experience of MIT. When I began taking courses at MIT, I worked my proverbial ass off in a very difficult class in CS (course 6 by their parlance) and got an A. After the semester was over, I found out that students generally work together on labs, which was a major portion of the class, and would have significantly lightened my load. (Talking about spending entire weekends with hands-on-keyboard, very unreasonable amount of work for one person, even an overachieving one such as myself)
This is a _cultural_ difference of MIT; people tend to work with one another, or they tend to fail. They learn it freshman year, and it's ingrained in their psyche from then on.
Interestingly, the line between cooperative work and cheating is difficult to discern and mostly set up by the professor. When the professor does not say one way or another if the work is collaborative, students will generally consider it collaborative.
As for the "[n]ever build cool things" troll, I'll let you google the number of neat inventions by famous MIT / Harvard alums; I won't waste my time.
Not what I meant. I'm actually in favor of people working collaboratively on problems, I'm talking about computer-servers full of P-Set solns, essays, old tests, occasionally the sale of these for money, etc etc etc.
As I get older, I find the abstractions to be much more interesting; how does one express a lambda in assembly? Functional programming in general? The simplicity of Python and the beauty of Lisp / Scheme / f# keep me going as a programmer.
I wonder, as assembly languages become more complex and malformed with the introduction of ARM and all of the headaches of custom architectures, if there won't be more people moving to the higher level, just for sanity's sake.
Actually, functional programming is very straight forward on a low level.
When you define a function, foo, the machine code for that function is at a specific memory location. When the source code says foo(*args), the machine pushes local variables, its current location in the code, and the args to the stack.
It then jumps to the memory location stored in foo
Once there, the code pops the arguments, does stuff, pushes the return value, and jumps back to where it was called from.
Once there, the return values and local variables get pop'ed, and execution continues.
Different compilers might use different conventions, but for our purposes this is a good enough model.
The way a normal function call would look in assembly might be:
mov %eax <returnPoint> ;at assembly time, <returnPoint> is replaced with the memory address of the operation labled returnPoint:
push %eax ;save the return point to the stack
push %ebx ;push local variables and the arguments
...
jmp <foo> ;jump to the memory location labled foo
returnPoint: pop ebx ;pop local variables and return values,
pop ecx
...
The thing to note in this example is that when you run the assembler, <foo> gets replaced with the memory location of the function code. If we want to a functional type thing, we need the address we jump to be able to change at runtime, so instead of having the assembler hard code the memory location to jump to, we need to get that information from a variable. This would look like
...
jmp [foo]
...
This time, foo is not pointing to a function, but rather to the memory location of a function pointer. This means that if we want to make it so when we call foo(), we run the bar() function, we would simply need to do:
mov foo <bar>
foo is the memory location of the function pointer, and <bar> is the memory location of the function itself, so now when we dereference foo in the jmp, we will execute bar().
With regard to the ARM architecture, I've done a little bit of work in it, and it isn't more complex than x86.
The viruses (this and skywiper) appear to be both targeting the middle east... Maybe they're all just chumps and easy targets out there, but it also makes sense that they have the same people behind them.
Really? That sounds like it'd be very inefficient when performing context-switching heavy tasks. Does OSX just take the cache penalty or does it somehow compensate with carefully written syscalls?
TL; DR
- No proof / source code / details on the backdoor
- Outlandish claims of this being a "stuxnet" weapon
Show me some source, a schematic, or a technique that you're using, and then I might believe you, otherwise this is just FUD. They didn't even name the bloody chip.
I'm going to go ahead and play devil's advocate; I think concern over this is really overblown. There are two things about this case that I don't really get:
1. If you're blasting your data over an unencrypted wifi connection, do you have a reasonable expectation of privacy? This seems to be equivalent to someone screaming the contents of their email, and then getting angry at you for eavesdropping. Also, who the hell transfers that kind of data over anything but SSL?
2. What was Google trying to get out of these packets, besides wifi-GPS data? This seems like more of a simple overstep of collection than anything else. Do we seriously think that this data was collected maliciously? They already have the majority of people's data, what more would they be trying to get? After all of my DNS lookups, my GPS coordinates, my email, and my social connections, what more is there?
> If you're blasting your data over an unencrypted wifi connection, do you have a reasonable expectation of privacy? This seems to be equivalent to someone screaming the contents of their email, and then getting angry at you for eavesdropping.
Exactly. I agree with other commenters that Google is not to be trusted, but I think this article isn't even specific to Google--it's just another illustration that unencrypted Wifi is public, and anyone with half a clue should know that by now.
> 1. If you're blasting your data over an unencrypted wifi connection, do you have a reasonable expectation of privacy?
Yes, you have a reasonable expectation of privacy. Connecting to someone's unsecured wifi is a criminal offence; scooping data from that connection maybe in some jurisdictions.
People may be stupid for not securing their wifi. But no-one at Google is stupid. They don't have that excuse.
> Do we seriously think that this data was collected maliciously?
Not being evil isn't a magic pass for being daft. Google should have known better. The engineer raised concerns, so at least one person knew it might have been a problem. Google has lived through years of people being concerned about privacy. How can they get something so simple so wrong?
