Samba

Planet Samba

Here you will find the personal blogs of Samba developers (for those that keep them). More information about members can also be found on the Samba Team page.

April 14, 2014

Andreas

Group support for cmocka

Last Friday I’ve released cmocka 0.4.0. It has several bugfixes and at least two new features. One is support for groups. This means you can define a setup and teardown function for a group of unit tests. I think some people have been waiting for this.

You can find an example here. It is simple and easy to use.
The other small feature is a new macro: assert_return_code(). It is designed for standard C function return values which return 0 for success and less than 0 to indicate an error with errno set. It will produce a nice error message! The rest are bugfixes and improvements for error message.

Thanks to all contributor and bug reporter!

If you think cmocka is a great piece of software, please vote it up on stackoverflow, thanks.

flattr this!

April 14, 2014 04:24 PM

March 24, 2014

Rusty

Legal Questions About Localbitcoins.com and Australia

As my previous post documented, I’ve experimented with localbitcoins.com.  Following the arrest of two Miami men for trading on localbitcoins, I decided to seek legal advice on the sitation in Australia.

Online research led me to Nick Karagiannis of Kelly and Co, who was already familiar with Bitcoin: I guess it’s a rare opportunity for excitement in financial regulatory circles!  This set me back several thousand dollars (in fiat, unfortunately), but the result was reassuring.

They’ve released an excellent summary of the situation, derived from their research.  I hope that helps other bitcoin users in Australia, and I’ll post more in future should the legal situation change.

March 24, 2014 04:01 AM

March 19, 2014

Rusty

Bitcoin Trading In Australia

I bought 10 BTC to play with back in 2011, and have been slowly spending them to support bitcoin adoption.  One thing which I couldn’t get reliable information on was how to buy and sell bitcoin within Australia, so over the last few months I decided to sell a few via different methods and report the results here (this also helps my budget, since I’m headed off on paternity leave imminently!).

All options listed here use two-factor authentication, otherwise I wouldn’t trust them with more than cents.  And obviously you shouldn’t leave your bitcoins in an exchange for any longer than necessary, since most exchanges over time have gone bankrupt.

Option 1: MtGox AUD

Yes, I transferred some BTC into MtGox and sold them.  This gave the best price, but after over two months of waiting the bank transfer to get my money hadn’t been completed.  So I gave up, bought back into bitcoins (fewer, since the price had jumped) and thus discovered that MtGox was issuing invalid BTC transactions so I couldn’t even get those out.  Then they halted transactions altogether blaming TX malleability.  Then they went bankrupt.  Then they leaked my personal data just for good measure.  The only way their failure could be more complete is if my MtGox Yubikey catches on fire and burns my home to the ground.

Volume: Great (5M AUD/month)
Price Premium: $25 – $50 / BTC
Charge: 0.65%
Hassle: Infinite
Summary: 0/10

Option 2: localbitcoins.com

According to bitcoincharts.com, localbitcoins is the largest volume method for AUD exchange.  It’s not an exchange, so much as a matching and escrow service, though there are a number of professional traders active on the site.  The bulk of AUD trades are online, though I sold face to face (and I’ll be blogging about the range of people I met doing that).

localbitcoins.com is a great place for online BTC buyers, since they have been around for quite a while and have an excellent reputation with no previous security issues, and they hold bitcoins in escrow as soon as you hit “buy”.  It’s a bit more work than an exchange, since you have to choose the counter-party yourself.

For online sellers, transfers from stolen bank accounts is a real issue.  Electronic Funds Transfer (aka “Pay Anyone”) is reversible, so when the real bank account owner realizes their money is missing, the bank tends to freeze the receiving (ie. BTC seller’s) bank account to make sure they can’t remove the disputed funds.  This process can take weeks or months, and banks’ anti-fraud departments generally treat bitcoin sellers who get defrauded with hostility (ANZ is reported to be the exception here).  A less common scam is fraudsters impersonating the Australian Tax Office and telling the victim to EFT to the localbitcoins seller.

Mitigations for sellers include any combination of:

  1. Only accepting old-fashioned cash deposits via a branch (though I’m aware of one US report where a fraudster convinced the teller to reverse the deposit, I haven’t heard of that in Australia)
  2. Insisting on “localbitcoins.com” in the transfer message (to avoid the ATO fraud problem)
  3. Only dealing with buyers with significant reputation (100+ trades with over 150 BTC is the Gold Standard)
  4. Insisting on real ID checking (eg. Skype chat of buyer with drivers’ license)
  5. Only dealing with buyers whose accounts are older than two weeks (most fraudsters are in and out before then, though their reputation can be very good until they get caught)
  6. Only allowing internal transfers between the same bank (eg. Commonwealth), relying on the bank’s use of two factor authentication to reduce fraud.

Many buyers on localbitcoins.com are newcomers, so anticipate honest mistakes for the most part.  The golden rule always applies: if someone is offering an unrealistic price, it’s because they’re trying to cheat you.

Volume: Good (1M AUD/month)
Price Premium: $5 – $20 / BTC
Charge: 1% (selling), 0% (buying)
Hassle: Medium
Summary: 7/10

Option 3: btcmarkets.net

You’ll need to get your bank account checked to use this fairly low-volume exchange, but it’s reasonably painless.  Their issues are their lack of exposure (I found out about them through bitcoincharts.com) and lack of volume (about a quarter of the localbitcoins.com volume), but they also trade litecoin if you’re into that.  You can leave standing orders, or just manually place one which is going to be matched instantly.

They seem like a small operation, based in Sydney, but my interactions with them have been friendly and fast.

Volume: Low (300k AUD/month)
Price Premium: $0 / BTC
Charge: 1%
Hassle: Low
Summary: 7/10

Option 4: coinjar.io

I heard about this site from a well-circulated blog post on Commonwealth Bank closing their bank account last year.  I didn’t originally consider them since they don’t promote themselves as an exchange, but you can use their filler to sell them bitcoins at a spot rate.  It’s limited to $4000 per day according to their FAQ.

They have an online ID check, using the usual sources which didn’t quite work for me due to out-of-date electoral information, but they cleared that manually within a day.  They deposit 1c into your bank account to verify it, but that hasn’t worked for me, so I’ve no way to withdraw my money and they haven’t responded to my query 5 days ago leaving me feeling nervous.  A search of reddit points to common delays, and founder’s links to the hacked-and-failed Bitcoinica give me a distinct “magical gathering” feel.

Volume: Unknown (self-reports indicate ~250k/month?)
Price Premium: $0 / BTC
Charge: 1.1% (selling) 2% (buying)
Hassle: Medium
Summary: 4/10

If you trade, I’d love to hear corrections, comments etc. or email me on rusty@rustcorp.com.au.

March 19, 2014 02:57 AM

February 25, 2014

Andreas

The Gold Linker

After the Update to Fedora 20 I forgot to update the linker to Gold. Today I released that linking Samba is horribly slow. Time to change the linker to Gold again:

Fedora:

ll /etc/alternatives/ld
/usr/sbin/alternatives --set ld /usr/bin/ld.gold

openSUSE:

ll /etc/alternatives/ld
/usr/bin/update-alternatives --set ld /usr/bin/ld.gold

flattr this!

February 25, 2014 03:25 PM

February 13, 2014

Holger

SMBTA downloads available through it’s GitHub site

Since our download server got down without further notice, we are working on moving the official download place under the samba.org realm. Meanwhile, SMBTA sources are available through it’s GitHub project releases page. Updated the Download Page.


hhetter123

February 13, 2014 12:12 PM

February 05, 2014

Rusty

Pettycoin and working with limited visibility.

At linux.conf.au I gave a last-minute talk previewing my work on pettycoin (video, slides), an experiment to shard a bitcoin-like network.  The idea is to trade off some security and robustness in return for scale, but use it only for small amounts where fraud is less worthwhile.  On the bitcoin network today this is already seen with zero-confirmation transactions, and this is the niche pettycoin seeks to fill.

There are numerous problems to be overcome (one being the time taken by my day job, of course).  But segmenting the network and the blockchain is an interesting challenge: bitcoin’s blockchain is already designed so that you can have partial knowledge (mainly so you can prune used outputs).  But there’s a clear divide between full nodes, and second-class partial nodes.  I want a system where no one need know everything, and I’m getting closer to that goal.

Consider the simplest useful transaction in the bitcoin network, with one input (ie. a previous transaction’s output) and one output.  To verify this is a fairly simple process:

  1. Is the transaction well-formed?
  2. Find the transaction whose output this is spending.
  3. Does the signature match the address of that output?
  4. Has that output already been spent?

With bitcoin, you’re expected to know every transaction with unspent outputs, so if you can’t find the transaction at step 2, the verification fails. Even better, you can verify that previous transaction, too, all the way back to the creating of the coins involved.  Your only worry is that the blockchain you have is the same as everyone else’s, so they’ll accept your transaction later.

If you don’t expect to know everything, it’s more difficult.  You can use a merkle proof to show that a transaction was present in a block; it takes just log(N) hashes for an N-transaction block.  So you could prove that all those previous transactions are in the blockchain (though that might be thousands of transactions) by providing me with each transaction and proof.

But this can’t prove that there are not duplicate transactions in the blockchain itself.  Only knowing the entire contents would do that.  So we’re relying on the rest of the network, each with a partial view, to check that didn’t happen.

This leads to the two requirements for any aspect of the pettycoin system which a node can’t verify by itself:

  1. The information to verify must be seen by some honest nodes.
  2. Each node must have an efficient way of reporting if it sees a problem.

The former is a bit tricky.  Consensus is formed by the blockchain, but you don’t want to see all of it.  You might expect to see some fraction of it, but if you don’t, how would you alert the network in a way that can’t be faked?   Imagine a miner holds back 5 transactions in the block, the miner might wait for your complaint message on one, then release that transaction making you look like the dishonest one.  By making you cry wolf, they can ensure you are ignored.

The solution used in pettycoin is that miners have to prove that they know the transactions in the 10 previous blocks.  They do this by hashing the transactions from the previous block into a merkle tree like normal, only they prefix each transaction with their payout address (this is called prev_merkle in the code).  The only way to generate this hash is to know the contents of each transaction, and you can’t make a valid block without it.  Unfortunately, the only way to demonstrate that this hash is wrong (thus the block is invalid) is to also know the contents of each transaction in the block.  Thus transactions are batched into groups of 4096; you only need send 4096 transactions to prove that one of the hashes in a block is wrong.  Miners will insist on knowing the transactions for those blocks, knowing that if they fake it they’ll likely be caught.

Reporting most other problems in a block is fairly:

  1. You can prove a duplicate spend in the block chain by showing both transactions and the merkle proofs that they are in each block.  The second block is invalid.
  2. You can prove a malformed transaction by showing the transactions and the merkle proof it is in the block.  That block is invalid.
  3. You can prove an overspend by showing the transactions used as inputs.  That block is invalid.

But if a transaction in a block relies on an output of a transaction which never existed, you can’t prove it.  Even if you know every transaction which ever happened, you can’t prove that to me (without sending me the whole blockchain).  The initial design lived with such warts in the blockchain, instead insisting that you would have to show all the predecessors when you paid me (via a payment protocol).  That predecessor tree quickly becomes unwieldy, however.

The new approach is that for each input of a transaction in the blockchain, the miner has to include the block and transaction number where it appeared.  Now anyone who knows that previous transaction can check it, and if there’s a problem it’s easy for any node to prove by showing the transaction which is in that previous block (with merkle proof that it is).

This means that the blockchain can be trusted, if half the mining power can be trusted.  This is a weaker guarantee that bitcoin, but sufficiently strong for pettycoin.  If you send me a new transaction along with transactions it uses as inputs  and merkle proofs that they are in the blockchain, I only need ensure that the new transaction isn’t a double-spend.  That’s the same as the bitcoin network, with zero-confirmation transactions (though pettycoin has a special double-spend report message to expedite it a little).

Next post, I’ll respond to the best criticism of pettycoin yet, the problem of gateways (by Jason Gi)…

February 05, 2014 07:49 AM

February 03, 2014

Andreas

cwrap 1.0.0 – testing your full software stack …

on one single machine!

FOSDEM/Brussels, February 2nd, I gave a talk about cwrap. I announced and released version 1.0.0 of cwrap, a set of tools to create a fully isolated network environment to test client/server components on a single host.
It provides synthetic account information, hostname resolution and privilege separation support. The heart of cwrap consists of three libraries you can preload to any executable.
The libc wrapper project does not require virtualization and can be used to build environments on different operating systems. The project
consists of a socket wrapper, NSS module wrapper (users, groups, hosts), and a (s)uid wrapper with support for GNU/Linux, BSD and Solaris.

The origin of these wrappers is the Samba project, where the wrappers are in use since many years to successfully test their protocol implementations. Now it is possible to use them outside of the Samba project. The wrappers have been improved and are loaded with new features.

Learn more at http://cwrap.org/

flattr this!

February 03, 2014 10:26 AM

January 26, 2014

Andreas

FOSDEM: My talk about cwrap

Next weekend, February 1st and 2nd, will be the FOSDEM conference in Brussels again. I will be there and give a talk in the Testing and Automation devroom. I hope you will be there and watch my presentation on Sunday, February 2nd, 11:30, Room: UD2.218A.

cwrap talk

See you there!

flattr this!

January 26, 2014 05:32 PM

January 14, 2014

David

Samba Transparent File Compression on Btrfs

I recently implemented support for the SMB ioctls required to allow clients to remotely manipulate file and directory compression flags on Btrfs.

Windows Explorer provides the ability to flag files and folders for transparent compression via the File->Properties->Advanced dialog box:

Windows Explorer Advanced Attributes Dialog
 
Files flagged for compression are transparently compressed and uncompressed by the underlying filesystem when accessed or modified, which normally means that storage capacity is saved at the expense of extra CPU overhead during file I/O.

New files and folders inherit the compression flag from the parent folder, unless created with the FILE_NO_COMPRESSION option.

Once flagged, Windows explorer presents compressed files and folders differently to those that aren't compressed:

Windows Explorer Directory Listing
This feature will be available with the upcoming release of Samba 4.2, and is enabled with the Btrfs Samba VFS module. E.g.:
...
[share]
vfs objects = btrfs
path = /mnt/btrfs_fs

January 14, 2014 05:10 PM

January 08, 2014

Andreas

libssh 0.6.0 released

After another development cycle, this time of 2,5 years, the libssh Team is proud to announce version 0.6.0 of libssh.

The most important functionality which has been added is a new callback-based server API. Also we added ECDSA support and a new algorithm called curve25519-sha256@libssh.org for key exchange to have something better than the NIST curves. OpenSSH also uses curve25519-sha256@libssh.org as the default for key exchange. For ECDSA there is a complete new API for public key management available. Also a big improvement is Kerberos support which has been tested by Red Hat engineers with FreeIPA and gssproxy.

Thanks to all contributors!

flattr this!

January 08, 2014 07:31 PM

Chris

Shanghai SMB3 Plugfest 2013

A Plugfest is a gathering of geeks; an opportunity for developers from different organizations to get together and throw virtual snowballs at one another’s products to see what breaks.  Plugfests are supposed to be fun, but also productive.  Participants learn new things about their own code (where it’s weak, where it’s limited), but also learn as much as they can about the competition and the underlying technology that brings them all together.

An SMB Plugfest focuses on interoperability with the Server Message Block network file protocol; the one that’s favored by Microsoft, the one that lets you map the Q: drive to the server.  SMB is also the protocol that Samba runs, and it is used in all sorts of devices from cellphones to home office file servers to big-iron data storage systems.  There are very few people who really know the guts of SMB, and I am one of those “lucky” few.

So I go to SMB Plugfests whenever I can.

These days, I go as part of a product team working on merging Samba with GlusterFS, a distributed file system that lets you build a scalable storage array from standard-issue PCs. The tough part for us is getting Samba to run on all of those PCs as if it were running on a single machine.  It’s a challenge, but we have a few tricks up our collective sleeves.

In early December 2013, Microsoft held an SMB Plugfest in Shanghai.  I got to go, and I was able to bring along two of my colleagues from Bangalore.

Geeks are attracted to the light of the monitor screen.

This is what a Plugfest should look like.

We spent the first day setting up the test gear.  For the remainder of the event we worked directly with Microsoft’s test suite developers and also attracted the attention of engineers from other participating companies.  We focused our efforts on learning how to use Microsoft’s new SMB3 test suite, and seeing how it behaved when aimed at our Samba-GlusterFS server setup.

We did find some issues in our configuration, and we gave Microsoft a lot of feedback on their test suite.  As an Open Source group, we also spent time working with other participants, helping them with their testing and explaining what we could about the odd behaviors they were seeing in their results.

Experience makes a difference.

January 08, 2014 01:41 AM

December 30, 2013

David

Git send-email PATCH version subject prefix

I use git send-email to submit patches to developer mailing lists. A reviewer may request a series of changes, in which case I find it easiest to make and test those changes locally, before sending a new round of patches to the mailing list with a new version number:

git send-email --subject-prefix="PATCH v4" --compose -14

Assigning a version number to each round of patches allows me to add a change log for the entire patch-set to the introductory mail, e.g.:
From: David Disseldorp 
Subject: [PATCH v4 00/14] add compression ioctl support

This patch series adds support for the FSCTL_GET_COMPRESSION and
FSCTL_SET_COMPRESSION ioctls, as well as the reporting of the current
compression state via the FILE_ATTRIBUTE_COMPRESSED flag.

Hooks are added to the Btrfs VFS module, which translates such requests
into corresponding FS_IOC_GETFLAGS and FS_IOC_SETFLAGS ioctls.

Changes since v3 (thanks for the feedback Jeremy):
- fixed and split copy-chunk dest unlock change into separate commit

Changes since v2:
- Check for valid fsp file descriptors
- Rebase atop filesystem specific selftest changes
- Change compression fsctl permission checks to match Windows behaviour
+ Add corresponding smbtorture test

Changes since v1:
- Only use smb_fname and fsp args with GET_COMPRESSION. The smb_fname
argument is only needed for the dosmode() code-path, fsp is used
everywhere else.
- Add an extra SetInfo(FILE_ATTRIBUTE_COMPRESSED) test.

GIT: [PATCH v4 01/14] selftest/s3: expose share with FS applicable config
...

December 30, 2013 01:29 PM

November 24, 2013

Andreas

Powerline

I spent the day to look at tmux and vim and found a lot of great plugins. What I really like for tmux and also vim is powerline. Powerline is a status-line and prompts utility to change the look and feel of your vim or tmux status lines. It looks like this:

vim

It consists of a special font, a python tool and plugins for applications. I’ve created package for Fedora and submitted a review request here.

flattr this!

November 24, 2013 08:09 PM

November 21, 2013

Andreas

CM: chromium doesn’t build with JDK 1.7

If you build Android or CyanogenMod and you run into issues with HashSet_jni.h you need the following changes to the chromium_org project:

diff --git a/base/android/jni_generator/jni_generator.py b/base/android/jni_generator/jni_generator.py
index de865d5..d4a2324 100755
--- a/base/android/jni_generator/jni_generator.py
+++ b/base/android/jni_generator/jni_generator.py
@@ -555,18 +555,21 @@ class JNIFromJavaSource(object):
contents)
return JNIFromJavaSource(contents, fully_qualified_class)

+def MultipleReplace(string, rep_dict):
+ pattern = re.compile("|".join([re.escape(k) for k in rep_dict.keys()]), re.M)
+ return pattern.sub(lambda x: rep_dict[x.group(0)], string)

class InlHeaderFileGenerator(object):
"""Generates an inline header file for JNI integration."""

def __init__(self, namespace, fully_qualified_class, natives,
called_by_natives):
- self.namespace = namespace
- self.fully_qualified_class = fully_qualified_class
+ self.namespace = MultipleReplace(namespace, {'':''})
+ self.fully_qualified_class = MultipleReplace(fully_qualified_class, {'':''})
self.class_name = self.fully_qualified_class.split('/')[-1]
self.natives = natives
self.called_by_natives = called_by_natives
- self.header_guard = fully_qualified_class.replace('/', '_') + '_JNI'
+ self.header_guard = MultipleReplace(fully_qualified_class, {'/':'_', '':''}) + '_JNI'

def GetContent(self):
"""Returns the content of the JNI binding file."""

In addition I needed to fix LinkNode in the Gallery app.

flattr this!

November 21, 2013 10:31 AM

November 18, 2013

David

Samba Server-Side Copy Offload

I recently implemented server-side copy offload support for Samba 4.1, along with Btrfs filesystem specific enhancements. This video compares server-side copy performance with traditional copy methods.


A few notes on the demonstration:
  • The Windows Server 2012 client and Samba server are connected via an old 100 Mb/s switch, which obviously acts as a network throughput bottleneck in the traditional copy demonstration.
  • The Samba server resembles the 4.1.0 code-base, but includes an extra patch to disable server-side copy requests on the regular share.

Many thanks to:
  • My colleagues at SUSE Linux, for supporting my implementation efforts.
  • The Samba Team, particularly Metze and Jeremy, for reviewing the code.
  • Kdenlive developers, for writing a great video editing suite.

November 18, 2013 08:21 PM

November 10, 2013

Jelmer

The state of distributed bug trackers

A whopping 5 years ago, LWN ran a story about distributed bug trackers. This was during the early waves of distributed version control adoption, and so everybody was looking for other things that could benefit from decentralization.

TL;DR: Not much has changed since.

The potential benefits of a distributed bug tracker are similar to those of a distributed version control system: ability to fork any arbitrary project, easier collaboration between related projects and offline access to full project data.

The article discussed a number of systems, including Bugs Everywhere, ScmBug, DisTract, DITrack, ticgit and ditz. The conclusion of our favorite grumpy editor at the time was that all of the available distributed bug trackers were still in their infancy.

All of these piggyback on a version control system somehow - either by reusing the VCS database, by storing their data along with the source code in the tree, or by adding custom hooks that communicate with a central server.

Only ScmBug had been somewhat widely deployed at the time, but its homepage gives me a blank page now. Of the trackers reviewed by LWN, Bugs Everywhere is the only one that is still around and somewhat active today.

In the years since the article, a handful of new trackers have come along. Two new version control systems - Veracity and Fossil - come with the kitchen sink included and so feature a built-in bug tracker and wiki.

There is an extension for Mercurial called Artemis that stores issues in an .issues directory that is colocated with the Mercurial repository.

The other new tracker that I could find (though it has also not changed since 2009) is SD. It uses its own distributed database technology for storing bug data - called Prophet, and doesn't rely on a VCS. One of the nice features is that it supports importing bugs from foreign trackers.

Some of these provide the benefits you would expect of a distributed bug tracker. Unfortunately, all those I've looked at fail to even provide the basic functionality I would want in a bug tracker. Moreso than with a version control system, regular users interact with a bug tracker. They report bugs, provide comments and feedback on fixes. All of the systems I tried make these actions a lot harder than with your average bugzilla or mantis instance - they provide a limited web UI or no web interface at all.

Update: LWN later also publishe articles on on SD and on Fossil. Other interesting links are Eric Sink's article on distributed bug tracking (Erik works at Sourcegear who develop Veracity) and the dist-bugs mailing list.

November 10, 2013 06:23 PM

Quantified Self

Dear lazyweb,

I've been reading about what the rest of the world seems to be calling "quantified self". In essence, it is tracking of personal data like activity, usually with the goal of data-driven decision making. Or to take a less abstract common example: counting the number of steps you take each day to motivate yourself to take more. I wish it'd been given a less annoying woolly name but this one seems to have stuck.

There are a couple of interesting devices available that track sleep, activity and overall health. Probably best known are the FitBit and the jazzed-up armband pedometers like the Jawbone UP and the Nike Fuelband. Unfortunately all existing devices seem to integrate with cloud services somehow, rather than giving the user direct access to their data. Apart from the usual privacy concerns, this means that it is hard to do your own data crunching or create a dashboard that contains data from multiple sources.

Has anybody found any devices that don't integrate with the cloud and just provide raw data access?

November 10, 2013 01:05 AM

November 05, 2013

David

Applying Git patches in bulk from Claws Mail

As a Samba developer, I often spend a large amount of time reviewing and testing patches submitted to the samba-technical mailing list. This often sees me jumping between my mailer (Claws Mail) and the console, with the following procedure:

  • Retrieve mail
  • For each patch in the proposed series:
    • Save to local disk in rfc822 format
  • Switch to console
  • For each patch in the series:
    • Apply to the local branch using git am
  • Review and test

The process itself isn't overly time consuming, but given the frequency, I decided to set about automating it slightly using Claws Mail's Actions feature:

Configuration->Actions dialog
I added the above Action, which:
  • Enters my Samba source directory
  • Runs git am with arguments corresponding to all selected messages (%F)
With this simple one-liner, I can select a bunch of patch mails and apply them all to my local tree in one fell swoop.

Action IO dialog, triggered via Tools->Actions->samba_patch_git

I'm content with this approach, but readers should note that there are a number of pitfalls, namely:
  • Patch mails must be in a format that git am can parse. E.g. git send-email
  • The git repository needs to be in a state ready to accept the patches

    November 05, 2013 12:28 AM

    November 03, 2013

    Andreas

    Curve25519-SHA256 is the default KEX in openSSH too now!

    Since some hours curve25519-sha256@libssh.org is the default KEX in OpenSSH!

    curve22519

    Several weeks ago Aris added a new Elliptic Curve algorithm for key exchange using Curve25519. After he wrote some kind of a RFC and implemented it in libssh he started to suggest a patch for OpenSSH which finally has been integrated.

    flattr this!

    November 03, 2013 12:36 PM

    October 17, 2013

    Rusty

    linux.conf.au 2014: Rusty’s Must See List

    Delightedly finished reading through the linux.conf.au program.  Some nasty clashes have me still arguing with myself, but here are my personal compulsory attendance talks.  Your preferences will no-doubt differ, so I’ve tried to explain my reasons:

     

    • Tridgell: Open Hardware Differential GPS – I spoke to Tridge about this, and the abstract completely undersells it.
    • Corbet: Kernel – Jon’s kernel talks are great for non-kernel people, but for me it’s about seeing the forest through the trees.
    • McKenney: Parallel Verification – Paul’s spoken with me about this, but I want to hear the practical side to see how I can apply it.
    • Heo: Kernel per-cpu  – I persuaded Tejun to submit this; his per-cpu work was elegant (mine, on which this was built, was merely functional).
    • Airlie: Virtual GPU – Sorry Bdale (with whom it clashes): I have wanted a virtio GPU for so long, I need to see it.
    • Packard: Zero-copy Compositing  – Keith is always good, and graphics performance is fascinating.
    • Suehle: Raspberry Pi – Generally O’Reilly books are well researched, so I expect great content here.
    • Isaacs: CTDB Bugs – I was around when he was finding some of these, and there are some fascinating surprises here.

    October 17, 2013 01:07 AM

    Last updated: April 21, 2014 01:00 AM

    Donations


    Nowadays, the Samba Team needs a dollar instead of pizza ;-)

    Beyond Samba

    Find help to make Samba fly!

    You won't be alone with your problem

    Releases

    Current stable release
    Release History

    Versions & Notes

    Maintenance

    Patches · Security Updates · GPG Key