Orva

Actually comparing Arm versus x86 is really like comparing apples to oranges. One is RISC, other is CISC. One is good with running multiple threads on single core with highly sophisticated branch prediction, other concentrates having many low powered cores each hoarding threads. And this is very, very crude simplification.

Benchmarks tend to be always favor other camp, depending which attributes you are testing.

It also has remarkably little information.

I know it is supposed to be just introduction post, but still some research data and/or actual implementation should have been available. Now it is just "Intel has done that" and people should believe this is true.

> I'm not entirely sure why they did that, but my best guess is that ZeroMQ pretty much doesn't support TLS.

Yup, ZeroMQ doesn't support TLS.

These freedoms mentioned (with addition of free education) are called democracy in northern Europe. This is also why we have difficulty keeping straight face when someone claims that US has democracy.

> Intel should spec "to change screen brightness, write a value from 0 to 0xFF to this register"

There is already (mostly Intel made) spec for this kind of things. It's called ACPI. Which by the way Samsung started (partially) using not so long time a ago. Reason for that was that Microsoft was going to stop selling them Windows 7 OEM licenses unless Samsung starts using ACPI.

> TianoCore – Open Intel reference UEFI reference implementation, 7061 files, >100MB of code, 10% of size of Linux kernel. Bigger than Linux core kernel

From Garrets linuxconf.au talk, year ago. As it is reference implementation, it is pretty much untested in the wild. So you can expect those "slight changes" to be mostly bugfixes.

Punchline is that Intel DOES provide pretty much all code for UEFI. And it is still bad.

There is only 2 rules in kernel development which you can't break:

1. Kernel APIs to userland are always backwards compatible

2. If you break something, you will take responsibility

If maintainer breaks both of those rules, how can you accept patches from him/her ever again? Remember that amount of patches handled by kernel core team is enormous, you have to able to trust subsystem maintainers at least some degree. In corporate world this would have caused immediate "clear your desk" reaction.

They are writing it during this weekend, but press release for hackathon was month ago (http://pastebin.com/sKKnRL19) and if I recall correctly he was hinting something about this project month or two before that. So there has been time for planning.

And like Tuna-Fish said, Finnish high school courses are quite limited and self-contained.

Remote data wipe access to devices from cloud service. What could go wrong?

I might be waving hands here, but I got impression that actual components that do raw processing in GPU are not that complex. Complex part (and which produces the performance) is the pipeline feeding data into those units. GPUs are also programmable chips so even publishing driver that shows how graphic stack on GPU side is set up could potentially reveal whole architecture of that chip.

Any sources for that software stack part? Only information I managed to find was that AMD was contracted to create Xenos core, but there was no mentions who made software (I would assume AMD) and especially no information about licensing.

No sane open source driver developer would agree to NDA in order to write driver. You wouldn't be able to contribute any other driver project (in that specialty area, which might be vast) until your NDA ends.

And of course, device driver would tell people all the secrets that NDA forbids you to disclose.

Porting is not really so bad issue, problem is that all sound and input port code will not work after year or two because of libraries changing, forgotten and deprecated. What I really do hope that Steam will choose libraries which might concentrate development effort around those. That would be good thing for everyone, not just for game developers.

It gets only worse when you keep adding more binary files. After doing this for while your repo will not work unless you pack it, which will take horrific times. If it will succeed: my git was 'surprisingly' segfaulting when trying to acquire 16Gb of ram at once during pack operation. (I was trying to keep RAW-photos synced, git stopped working when there was about 4Gb of files stored.)

Git is made and optimized for text files, no big surprise that it doesn't cope very well with binaries.

Server side OAuth is easy to implement, even without any library: you just send login parameters and callback-url where you get actual token that can be used to authenticate user. Problem with natice client is that, well, you cannot give callback url that will always work (having http-server at client? clumsy, hotspots will block, etc.).

Only way (even with OAuth2, if I recall right Google documentation) to get "working" flow with natice apps is to give special parameter as callback-url, which will return validation token in html-page. From where you need scrape it. Maybe there will be something better after OAuth2 is finished, but for now: easier to make own authentication server and API to talk with it.

To get masters from "teaching track" in Finland (which is _very_ appreciated during job interviews) you need quite hefty load of padagogy and sosiology studies on top of your usual master's.

Chips that are able to put out more power than current netbooks and still fit into smarphones are not too far away, I'd expect those be ready for market in couple years. Handhelds would be phones that could also be used as laptops/dockable computers. Meego and Qt makes it almost trivial to make same apps work on touchscreen and also with traditional monitor/mouse/keyboard. Remember, the OS is not the platform anymore, it's the app ecosystem.

>Apple for one is known to be looking way ahead of "current market".

So was Nokia. So was Microsoft. It is easy get stuck into profitable segment and not to expand in fear of losses.

What I believe they are meaning with this is the next generation smartphone market, not the current one. WP7 and iOS will be needing total rework to fit in, whereas Meego is fine even at the moment (..when it is stable at least!). Targeting current market for complete takeover is just stupid, unless you are happy with dying out slowly.

Getting into margins now is job of WP7 platform. Symbian is not fit into smartphone field (use S^3 if you don't believe) and these guys realise it. True that Meego will need lot of work, but there should be enough time to polish it before market they should be targing opens.

Using IDEs with netbook is not really good experience: screen area is just too small for having all components on screen same time and you cannot help noticing that modern IDEs do need way too much resources to be smooth on such tiny machine. Netbooks cannot really be used like normal laptops: usually there is no other option than programs fullscreen, which in practise means you need virtual desktops. This effectively throws windows to the bin, but if that is not problem for you.. go ahead and get one. Just make sure you test it beforehand, many netbooks still have horrible keyboards!

Lately I have been doing most of my developing on netbook using vim and must say I love it. There is no performance problems with any scripting languages, not even while having mysql + rails/cakephp on. Only problem is compiling bigger projects when doing c/c++, but that isn't problem if you have access to box with more power like you suggested.

My own machine is Samsung n140, although my config is not the most usual one: stripped down arch + xmonad. Battery life while using wlan is from 10 to 14 hours. The reason why I ended to this particular machine is combination of awesome battery life + really nice keyboard, one of the best I have found from any laptop. Minus side is kinda low quality HDD which blew up quite fast, but I use this machine only on battery power with agressive spindowning and load count jumps into sky fast which can explain.