Slashdot Mirror

From the Rust Project FAQ:

Are you going to use this to suddenly rewrite the browser and change everything? Is the Mozilla Corporation trying to force the community to use a new language?
No. The Mozilla Corporation's involvement is at the labs level: the group concerned with doing experiments. The point is to explore ideas. There is currently no plan to incorporate any Rust-based technology into Firefox.
...
What are some non-goals?
...To cover the complete feature-set of C++, or any other language. It should provide majority-case features.

The absolutely brazen, bald-faced misinterpretation of what's going on here is stunning. They could not miss the point by more!

I just use sshuttle.

This is what they've been working on? It's centralized , for fucks sake Mozilla, what are you thinking? Any idiot can code something like this.

BrowserID is pretty simple. It's basically a single Javascript function that a website can call in the browser. This example on github shows the function that is called. The clientside code is then free to make requests to the server for a specific authentication mechanism, making it very flexible. The Server code just validates the username/password.

Personally, I think it's simpler to understand than things like OpenID which are convoluted and not standardized from the user point of view. Where is the standard account management protocol for OpenID?

An older Slashdot article on BrowserID for reference: http://www.yro.slashdot.org/story/11/07/15/1216222/Mozilla-BrowserID-Decentralized-Federated-Login

Not heard of Enigform but will look into it!

BrowserID is pretty simple. It's basically a single Javascript function that a website can call in the browser. This example on github shows the function that is called. The clientside code is then free to make requests to the server for a specific authentication mechanism, making it very flexible. The Server code just validates the username/password.

Personally, I think it's simpler to understand than things like OpenID which are convoluted and not standardized from the user point of view. Where is the standard account management protocol for OpenID?

An older Slashdot article on BrowserID for reference: http://www.yro.slashdot.org/story/11/07/15/1216222/Mozilla-BrowserID-Decentralized-Federated-Login

Not heard of Enigform but will look into it!

This submission looks like typical content farm / blogspam junk so here's some useful links instead:

• The BrowserID main page: https://www.browserid.org/
• Mozilla Identity Team's blog: http://identity.mozilla.com/
• Source Code: https://github.com/mozilla/browserid

it still is - right here.

now go download it right now before it gets removed.

it's only 44.21M.

and then ... lets torrent and roll ... lets share history.

I assume you mean http://www.tarsnap.com/scrypt.html and https://github.com/pbhogan/scrypt? Looks interesting, I'll have to check them out.

A better idea would be to switch to storing the SRP verifier:

x = H(s,p) ; s = salt, p = password, H() is SHA-1
v = g^x

Store v, s, and u (the username).

http://en.wikipedia.org/wiki/Secure_Remote_Password_protocol

Anyone who can get the password (or even the hash) from the above deserves to get them. :)

I assume you mean http://www.tarsnap.com/scrypt.html and https://github.com/pbhogan/scrypt? Looks interesting, I'll have to check them out.

Try the free open-source SparkleShare software and roll your your own cloud 100%. That would trump any cloud provider option if this is your concern, since all the disks and PCs are under your ownership and control. (Although you are correct in your technical arguments, for sure. I also like SpiderOak.)

SparkleShare is essentially a DropBox clone in terms of a GUI, which extends to recovering older versions with a right-click. It looks like DropBox, and it works like DropBox too. But it is just a scripted GIT environment. In fact if you already have a GIT Repo hosted on a server (or service) somewhere, SparkleShare is easily configured to wrk with it. Here's how you start from scratch, assuming you already have PGP keys shared with the server:

At the server, create a new, empty GIT repository:
git init --bare NEWREPOSITORY.git
At the workstation:

Normally, you might use something like the following commands to work with GIT. (these are not necessary if you use SparkleShare)

git clone ssh://user@example.com:port/home/user/NEWREPOSITORY.git
cd NEWREPOSITORY.git
git clone ssh://user@example.com:port/home/user/NEWREPOSITORY.git
The SparkleShare config:

Add Hosted Project...

Address:

ssh://user@example.com:port

Remote Path:

/home/user/NEWREPOSITORY.git

This document explains how to add a layer of encryption, (which also works to secure services like DropBox btw: https://github.com/hbons/SparkleShare/wiki/Encrypting-your-files-before-transfer

In real-life, those directions aren't so hard are they? But let me tell you now in real-life, I formatted this nicely in html and slashdot has been torturing me for 20 minutes as I tried to submit it well. Plain text option worked best, eventually.

They are already using the Arduino to do this . Which gives good results. Controlling a CNC any other way strikes me as stupid. Because you want some very hard real-time timing.

Example: https://github.com/bkubicek/Marlin

https://github.com/divegeek/uscode

When I ask the question, I don't expect perfection.

But I expect it from myself. I hate the feeling of walking out of the room and realizing that I made some dumb, should-be-obvious typo. I usually react to mistakes by laughing it off: "oops! Yep, I missed that. It should have been..." and moving on, but I still hate that I made them in the first place when I likely wouldn't if I'd been in a different setting.

There's a lot more going on in the interviewer's mind than playing 'cc'...

I've had it both ways. I don't write C often, but I've written some C that I'm proud of. I've been through some interviews (not for a position programming C!) where the whiteboard programming was basically "write some pseudocode to do a binary search", and then had a fun time playing "did you remember not to make an off-by-one error" and exploring other failure modes as you described in your other post. I've been through others where the interview was obsessing on whether I'd gotten the syntax right for type-punning a value stored in a char[4] to an int32_t.

I suspect you and I would have a good interview experience - regardless of who was asking the questions - but I promise that plenty of interviewers do things differently than you.

https://en.wikipedia.org/wiki/NASA_Open_Source_Agreement

Oh... and their projects are hosted at GitHub https://github.com/nasa/. That website in the summary is just the Homepage of those NASA projects hosted at GitHub.

Amazing that nobody mentioned Cascalog https://github.com/nathanmarz/cascalog

I was doing similar research a few days ago.

Some of these are already mentioned...

• Lessfs - v1 is stable, v2 is pre-alpha/alpha. http://www.lessfs.com/
• Blackhole - http://www.vanheusden.com/java/BlackHole/ - requires Java, which seems like a bad idea to me for a block level device, but I haven't tested it yet.
• SDFS from OpenDedup - http://code.google.com/p/opendedup/ - http://www.opendedup.org/ - looks very promising, but may have stalled
• Dedupfs for Ext3 - http://pages.cs.wisc.edu/~kosmatka/dedupfs/
• ZFS. You know about that.
• DragonFly/Hammer - http://www.dragonflybsd.org/hammer/ includes dedup. Competitor to ZFS and Btrfs, also using Btree. Includes block level dedup, but I'm not sure if it's fixed block or not. Suspect it is fixed.
• Btrfs - there's a patch. Not sure if it's in mainlined yet. But without fsck btfs is not trustworthy enough. That's coming soon, but has been for a while. In case you read this as being negative about btrfs, it's not; it's an awesome file system, combining modern ideas and an excellent implementation, but it's still at testing stage for critical data.

Other stuff:

• Dext2 - an idea. No code. http://code.google.com/p/binarywarriors/
• BackupPC, the next version may have block level dedup, it's been suggested/requested. Numerous people pointed out the hard linking scheme it uses. I'm backing up VM images, which is what started me on this block-level dedup search, and when you have a small change in a 60BG file, it's a new file. (Yes, I have thought of schemes to split them.)
• Bacula have been experimenting with block level dedup, fixed and sliding. May be in future versions.
• Bup - https://github.com/apenwarr/bup has many of the ideas. It's not a file system, but could be reconstructed, I think. Based on Git store. I recommend reading http://apenwarr.ca/log/ which has more, and is entertaining. I think this is an excellent approach. Read back in his blog for details on bup ideas.
• SquashFS - for static data.
• Epitome - http://www.peereboom.us/epitome/man/ - for static data too, I think. Not fully investigated.
• I know I saw at least one Google Summer of Code submission about dedup. Haven't followed it up yet, and couldn't find the tab in my browser.
• Interesting conversation - http://news.ycombinator.com/item?id=2932335

By fixed block I mean that the file system does not search out shared data when the blocks are not on block boundaries. So if you add one byte to the beginning of a 10 GB file, and that has the unfortunate consequence of rippling up through all the blocks that make the file, then there will be no block level sharing with the original file. Of course that's a pathological case, but you get the idea.

Original poster, perhaps you could keep us informed of your findings? There's at least me who is also interested.

The "serious professional" doesn't use PHP at all, lol.

But you carry on!

You might want to inform Facebook devs [1] that their language isn't "professional". Go on, I'll just wait here.

[1] https://github.com/facebook/php-sdk

Look at Amazon Cloud Services, they give you blank Linux elastic box and you can [relatively] easilily set it up there. Seconding Django. I've been using Django, then hybrid like https://github.com/hmarr/django-mumblr.

Before IBNIZ, viznut was using a C compiler to, well, discover minimal music. You should read his paper regarding algorithmic composition using small programs. und check out my repository of formulas for C programs that generate sound.

People without easy access to compilers (I met a gal a few days ago who had old OS X and no 99$ to spare for a dev account) should still check out a track from the repository as wave file to get an impression of the style.

I also wrote a program generating a crude chiptunes version of the IT crowd melody (of course, the melody is not algorithmically generated, but rather encoded in the source, feel free to consider that cheating).

I wrote something similar to IBNIZ, yet vastly simpler, a composing software called glitched (needs pygame 1.9.1). The forth variant I use has no subroutines or recursion and is not even turing complete and the stack has only 256 fields. However, it is compatible with that of several other implementations (see README). Like IBNIZ, it has live editing and stack visualisation.

It is important to note that sound made with this kind of tools is not limited to chiptunes. There is a video of an older version of glitched, doing Karplus-Strong-string synthesis.

(Apologies in advance to the users of a totally unrelated glitch library, which is also written in python. I have met one of it's developers last night and we agreed insane troll logic dictates a merger of our two projects to rectify the namespace collision. I may have to bring that up again when he is sober.)

THIS is bad ass:

Owned Over Amateur Radio (Remote kernel exploitation) [PDF]
http://vulnfactory.org/research/defcon-remote.pdf

rose-exploit â" Remote kernel exploit for ROSE amateur radio [code]
https://github.com/djrbliss/rose-exploit

Using Part 15 Wireless Ethernet Devices For Amateur Radio (AX.25 over Ethernet) [ftp/PDF]
ftp://ftp.tapr.org/software_lib/ether/Ham_Ethernet_GBPPR.pdf

Google: ax.25 over ethernet

THIS is the REAL global conspiracy!

Available here: https://gist.github.com/1529336

Received: from dmx1.bfi0.com (dmailer0121.dmx1.bfi0.com. [208.70.142.121]) by mx.google.com with ESMTP id v2si13633651ane.208.2011.12.28.10.17.18; Wed, 28 Dec 2011 10:17:18 -0800 (PST)

Interesting areas:

DKIM-Signature: v=1; a=rsa-sha1; d=email.newyorktimes.com; s=ei; c=simple/simple; DomainKey-Signature: q=dns; a=rsa-sha1; c=nofws;

I am bitter that Epiphany chose to tear out python and replace it with Javascript of all things.

Javascript is an unholy mess to debug, and it often fails silently in browsers, but I do have to admit that one can write fairly Python-like code in it.

I haven't personally used it, but CoffeScript is a really neat concept and very Pythonic.

Do people really have personalized home pages now that Facebook came about (other than some hobbyists or professionals who run a side business)?

I have a blog (tech notes: static pages compiled with Blogofile and my own photo album plugin). If I get bored with Facebook, I can disconnect without losing any of my posts or photos - or the links to them. If I want faster web hosting than my home DSL provides, I can upload the files to a dirt cheap static host. I have virtually unlimited space with no content restrictions, upload limits, or annual fees over what I'm already paying for Internet access. I definitely fall into your hobbyist/professional category but it's more that I want more control over my web presence than any social network would give me.

I just started building my own a few months ago and I'm pretty happy with the following:

Arch linux - has my favourite package manager (pacman + yaourt)
Xmonad window manager - tiling wm that doesn't get in the way, with some minor configurations
Stalonetray - has a clock (trayclock), sound (pnmixer), battery indicator (qbat), dropbox, etc.
ranger - vi-like file browser which is simple to use, runs in a terminal (urxvt), and I keep a regular filebrowser (nautilus) around just in case something needs me to drag-and-drop something.

non-visual things:
udiskie - automount usb drives and things

It's a very simple setup, though there are more things than what is mentioned here, and I love it. :)

A list of programs which I am currently using and why is here: https://github.com/MattWoelk/configuration-files/blob/master/home/matt/programs.txt Enjoy!

I work in a Java shop. We run Sun Java 6 on a mix of Solaris and Ubuntu. I'll be handrolling a deb from the Sun Java tarball precisely because not everything can be trusted to work identically between Sun Java 6 and OpenJDK 6.

We just recently hit a weird bug which turned out to be a "how did that ever work?" moment - revolving around different implementation-specific behaviours in Sun Java 6u24 for Solaris SPARC and Sun Java 6u26 for Linux.

We'll be moving to OpenJDK, but only after thorough testing. OpenJDK 6 is a proper Java, but we've discovered the hard way not to make any such move without thorough testing. Because programmers are human and bugs happen. Never trust, always verify.

Actually, since Oracle's JDK7 is based off of OpenJDK 7, OpenJDK 7 is more of a "proper" Java than OpenJDK 6.

I work in a Java shop. We run Sun Java 6 on a mix of Solaris and Ubuntu. I'll be handrolling a deb from the Sun Java tarball precisely because not everything can be trusted to work identically between Sun Java 6 and OpenJDK 6.

We just recently hit a weird bug which turned out to be a "how did that ever work?" moment - revolving around different implementation-specific behaviours in Sun Java 6u24 for Solaris SPARC and Sun Java 6u26 for Linux.

We'll be moving to OpenJDK, but only after thorough testing. OpenJDK 6 is a proper Java, but we've discovered the hard way not to make any such move without thorough testing. Because programmers are human and bugs happen. Never trust, always verify.

There's no clause in the GPL itself that permits such upgrade. What it does is spell out the formula that can be used by a developer to indicate that he wants to opt into upgrading:

9. The Free Software Foundation may publish revised and/or new versions
of the General Public License from time to time. Such new versions will
be similar in spirit to the present version, but may differ in detail to
address new problems or concerns.

Each version is given a distinguishing version number. If the Program
specifies a version number of this License which applies to it and "any
later version", you have the option of following the terms and conditions
either of that version or of any later version published by the Free
Software Foundation. If the Program does not specify a version number of
this License, you may choose any version ever published by the Free Software
Foundation.

And then the copyright notice for Linux states:

Also note that the only valid version of the GPL as far as the kernel
  is concerned is _this_ particular version of the license (ie v2, not
  v2.2 or v3.x or whatever), unless explicitly otherwise stated.

Since it does explicitly specify the version number, and does not invoke "any later version", there's no option to redistribute under GPLv3.

You don't see a 'Hello world' program requiring a 3GB+ build footprint do you?

Some come close though...

We've made a Debian chroot installer and manager app for Android, so you can have a Debian chroot running in parallel with Android. You can apt-get anything in Debian/arm. We're interested in server software, so we haven't tried anything beyond things like ssh, nginx, jabberd, etc.

https://guardianproject.info/code/lildebi/

And the code is up on Github:
https://github.com/guardianproject/lildebi

I think I'll take your mention of OpenOffice off on a tangent to do a little plug of my free software project...

A few months ago, I began the process of trying to port Apache POI to Android. For those who don't know, Apache POI is "the Java API for Microsoft Documents". It does Word and Excel, and also tries to implement other Microsoft formats, with various degrees of success.

I decided to start with a spreadsheet. I spent two weeks writing some scaffolding for a spreadsheet in Android. When I got it to where it looked good enough, I began working on loading Excel files with POI. And I could do so - with Excel xls files up to 2007. When I tried to load Excel 2007 and 2010 xlsx files, I ran into some problems...a topic which I'll get back to in a moment. Anyhow, I worked on trying to load Excel 2007/2010 xlsx files for a few more weeks, and when I saw I wouldn't, without luck, make any immediate breakthroughs, I put it aside. A few months later I open sourced my code on Github and cursorily described my 200/2010 problem in the README file. If anyone wants to look at it, feel free. As I said, I worked on features for two weeks and then got hung on one the 2007/2010 xlsx problem. The one big feature I did not include in the spreadsheet is the ability to finger swipe through the spreadsheet rows and columns - you can look around the spreadsheet with the arrow buttons on old, old Android phones and the Android emulator, but I spent all my time working on Excel 2007/2010 xlsx instead of features like that. It's only two weeks worth of work (plus the 2007/2010 xlsx work), and that minus my last six months of Android knowledge, but it's decent enough for what it is.

I sent a message to the POI mailing list after posting the code on Github. One of the POI dev's made a suggestion as to what to do - strip all non-Excel functionality from the schemas file - but that was what I already had for the most part done. I say for the most part because I probably stripped more than 80% of the non-Excel code. Why did I need to do this? Because Android Dalvik executables have a 65,536 method limit, and with all the Apache POI XSSF required libraries to do Excel 2007/2010 xlsx files included, my program would exceed that limit. Now there are two paths to get around this. One is the easier path - strip 100% of the POI stuff unneeded for Excel compatibility from the POI schemas jar. But I already stripped the low hanging fruit of this, and whittled 80+% of that stuff from the schema. Unless the other

Anyhow, back in July, when I stripped 80+% of the low-hanging fruit non-Excel schema and it was still a no-go, I put this aside and began working on other Android projects. In October I began thinking about this, and realized I was not going to get back to it in a while, so I cleaned it up (a little bit) and put it up on Github under the Apache 2.0 license (POI is Apache 2.0 so I figured I'd just use that as well), and posted to the POI mailing list.

I've had enough Android projects, and non-Android projects and things to distract me from returning to this. If my attention was turned to this again, the first thing I would do would be to repeat my 80+% non-Excel POI schema cleaning with the latest POI trunk (or last released jar, or whatever) and make my results public on a web page, or the POI mailing list or something. I would try to get it from 80%+ to 85+% and up to 100% clean of everything unneeded. If that didn't work, I would see if I could strip stuff from some of the other jar's, like xmlbeans or something.

If all of this didn't work, I would go the way of two Dalvik executable files in one Android project. With custom class loading, an interface for each needed method and all of that. An effort I seriously doubt I would start on my own - but who knows? If others were interested in this, I might put some more time and effort into it when I can. It would be nice to have a free software Excel-compatible spreads

Wouldn't it be great if laws were written using high quality, open, revision control?

The good folks at http://www.keepthewebopen.com have asked for our collaboration in helping them to write better legal code.

Fork at will!

And one can use hiphop to translate some existing web applications to the new framework. Very good post btw.

HipHop for PHP converts PHP into c++.

You're in good luck! The same author is developing a similar system in a client/server model, with the server (called Heliotrope) doing the actual work. You just need to write the Linux and Android clients. A client already exists, but it's ncurses based.

Also this may help you take system snapshots at a very granular level

Is Convergence foundering due to a lack of buy-in from trustworthy allies?

In your BlackHat 2011 talk you announced Convergence as a new way to establish trust on the internet to replace the SSL/Certificate Authority approach that has been shown to be so broken with the recent compromises of CAs like Comodo and Diginotar. Yet potential allies, some of whom admit that SSL has failed to meet its purpose and needs fixing, have not bought in to Convergence. Notably these include Google's Chrome security people and apparently the EFF (who has proposed a different solution instead).

While the list of Convergence notaries is still growing, there is so far a lack of support from the kind of allies like the EFF who could lend credibility and tip momentum toward widescale adoption of Convergence as a solution to the SSL/CA problem. Is Converence wilting on the vine?

Heh, like this one that just fixes the naming: https://github.com/liblime/LibLime-Koha/commit/41764c12a22ebfab7f28087a1a82153125894985

This is patently false. LibLime's Koha git repo is available on Github: https://github.com/liblime/LibLime-Koha. HLT community members have even submitted pull requests to our project.

This summary and the ensuing discussion are so full of dumb and FUD, it's hard to know where to start. I'll list a few bullets:

1) If managing one of the Navy's library catalogs makes PTFS/LibLime a "defense contractor," that's a serious diffusion of the term.

From the PTFS website: "PTFS’s Professional Support Services department specializes in staffing for Intelligence Agencies. "

2) PTFS/LibLime has held the same trademark continuously in the US for several years without any attempts to limit its use. The same applies to this trademark.

Considering the behavior of ptfs/liblime up to now, why would any reasonable person trust ptfs/liblime as a steward of the koha trademark?

3) PTFS/LibLime's project is also OSS: https://github.com/liblime/LibLime-Koha

Thank you for not referring to the ptfs/liblime fork as "koha".
By saying that "...PTFS/LibLime's project is also OSS," you seem to be acknowledging that it is separate from koha, so why not call it by a different name?

4) The LibLime component of PTFS is composed of fewer than a dozen people. PTFS as a whole is under 50... smaller than a lot of libraries.

Is the small size of ptfs/liblime supposed to excuse its abhorrent behavior and lack of moral compass?

The real issue here is that there is an unresolved project fork with an ugly, circuitous history. A conflict erupted over project direction and management, the "ownership" of the project was diffuse, and now both sides claim that they have rights to the name. Ironically, HLT is the side that claims that LibLime does not have rights to use the name.

False. HLT is the side that claims that LibLime should not be permitted to trademark the name "koha".

However, LibLime does not contend the converse, recognizing that plain fact that the name ownership is not clearly resolvable.

Everyone loves little neighborhood libraries, and everyone hates "big, evil defense contractors," so you can see who receives the benefit of the narrative frame. HLT is doing their best to work this framing, facts be damned. Meanwhile, they can't even take the issue seriously enough to stop their own trademark application from being abandoned from inattention.

So, are you saying that HLT is to blame for not taking "...the issue seriously enough to stop their own trademark..." from being acquired by ptfs/liblime? In other words, ptfs/liblime is not responsible for what it is doing, but HLT is to blame for allowing ptfs/liblime to to do it?? Wow, you folks at ptfs/liblime really have no moral compass at all.

It seems to me that ID's replacement sections 15 & 16 comply with section 7 of the GPLv3. The source code, remains, therefore, GPL3-compatible. https://github.com/TTimo/doom3.gpl/blob/master/COPYING.txt

The actual patent work-around is in https://github.com/TTimo/doom3.gpl/blob/master/neo/renderer/draw_common.cpp in the function RB_T_Shadow()

You can read the substituted implementation here: https://github.com/TTimo/doom3.gpl/blob/master/neo/renderer/tr_stencilshadow.cpp https://github.com/TTimo/doom3.gpl/blob/master/neo/renderer/tr_shadowbounds.cpp I won't pretend to fully understand it but it does seem to be an implementaion of shadow volumes.

You can read the substituted implementation here: https://github.com/TTimo/doom3.gpl/blob/master/neo/renderer/tr_stencilshadow.cpp https://github.com/TTimo/doom3.gpl/blob/master/neo/renderer/tr_shadowbounds.cpp I won't pretend to fully understand it but it does seem to be an implementaion of shadow volumes.

No, you are not correct.

The Dev Agreement forbids downloadable code, but it does not prevent interpreted code -- there was a small time when interpreted code was not allowed to call iOS APIs directly, but that restiction has been gone for a while now.

Lua is used widely in games on iOS, both directly and though SDKS like Corona. There is Wax a framework for writing Cocoa touch apps in Lua. In the App Store itself you will find 4-5 different Basic interpreters, a python interpreter, ruby, and the excellent iLuaBox.

You don't have to save full 32-bit PNG. 8-bit PNG supports full alpha as well -- in all applications except Photoshop.

See http://pngmini.com/ or https://github.com/pornel/improved-pngquant

Perhaps this will help

https://github.com/movitto/snap

"posted the fixed jar files for all ROM developers to use."
No, that's not for all ROM developers to use, that's only useful for ROM developers using the EXACT same base ROM that the NoCIQ mod was developed for.

It is utterly useless to anyone trying to remove CIQ from a ROM with a different base even for the same device, let alone someone trying to remove CIQ from a different device.

Now if they just had a high-level list saying "These are the jar files normally affected, these are the smali files normally affected within the .jar, and these are the function calls to look for in those files", it would be a LOT easier to port the NoCIQ mods to other devices.

Similar to what I did with mods to Settings.apk to allow NFC to work on the SGH-I777 - On IRC, it took me one sentence that two ROM devs had no trouble implementing:
"Search for NfcAdapter in WirelessSettings.smali, and delete the second occurrence of removePreference after that" - no need for anyone to find the original Settings.apk of my modified one to diff against.

And yeah, the power menu mod is a bitch - it fails frequently. I wasn't able to do it until gtg465x's commit at https://github.com/gtg465x/unnamed_rom/commit/1911cf0561bd278e86f1d238b272417b57d0b230 (As do many mods that involve adding something - removal mods are USUALLY easier.)

We've been fortunate in the SGH-I777 community - most of us came from the Infuse community, where nearly everyone worked together because there were few of us and the device was a massive fucking annoyance. As a result there's a lot of coordination and cooperation on IRC. Developers that choose not to coordinate/cooperate often find themselves unable to keep up - such as one guy that took almost a week to release sources for his kernel, and when he did so, just did an initial commit of his current source tree. Meets the letter but not the spirit of the GPL...

The problem is you have a lot of oldschool ROM cooks from the WinMo days, colliding with the open-source crowd, such as the Cyanogenmod team, and in my experience most of the better kernel hackers are the ones that post full git commit histories because they have nothing to hide AND believe in peer review. A lot of kernels are barely GPL-compliant (e.g. no source for betas, when source drops it's a megatarball) and when I read the threads for those, I see that whoever it is seems to have broken all sorts of things in the pursuit of ShinyUselessFeature that everyone asks for despite it not really being that useful and having major potential negative side effects.

Databases that are working on in-RAM workloads (so not I/O bound) spend most of their time moving data pages around in memory. There are few computational components to database work, compared with how often chunks of data are touched. Neither the floating point or integer speed is the real limiting factor on how fast that can happen. The size of the CPU caches and the speed of the CPU->RAM interconnect are the important factors.

I've been working on a memory oriented benchmark aimed at testing for this particular area of performance for a while now. The Intel vs. AMD situation is very complicated. It depends quite a bit on how many concurrent programs are running, especially on the big servers where you can't fully utilize all of the memory channels available. I see Intel as having an edge on smaller systems, their performance with only one or two cores going can be much better. At larger active core counts, the two manufacturers are much closer to equal. I don't see this new product line as changing that.

GitHub provides a friendly interface to view the source without having to use the repo tool and downloading the whole thing, so I'm eagerly waiting for this to get pushed there as well. Shouldn't take long.

https://github.com/android/