This feed omits posts by jwz. Just 'cause.
For a list of highlights, please see the previous post on -rc2; not much has changed since then.
[Previous list of "leftover bits" is here]
- "git config", when removing the last variable in a section, leaves an empty section header behind. Anybody who wants to improve this needs to consider ramifications of leaving or removing comments.
Cf. $gmane/219524 - Add "git pull --merge" option to explicitly override configured pull.rebase=true. Make "git pull" that does not say how to integrate fail when the result does not fast-forward, and advise the user to say --merge/--rebase explicitly or configure pull.rebase=[true|false]. An unconfigured pull.rebase and pull.rebase that is explicitly set to false would mean different things (the former will trigger the "fast-forward or die" check, the latter does the "pull = fetch + merge".
Cf. $gmane/225328
Malaysia has arrested opposition leaders for "promoting hatred against the government".
A government that arrests people for this, deserves all the hatred people choose to give it.
NOAA predicts an unusually severe hurricane season for the US east coast.
Israeli soldiers in Gaza shot and killed Muhammad al-Dura, age 12, in 2000. A cameraman make a video, which was broadcast. Now Israel claims that the whole thing was faked — but Muhammad's father asks, "If he's alive, where is he?"
Nowadays, in Syria, anonymous rebels fake video of atrocities. It is not absolutely impossible that Palestinians in Gaza would have done so. But the death of one Palestinian was so common that there was no need for anyone to fake that. (Israeli troops shot the ambuance driver!) This video was made, and sworn to, by a respected journalist. So the Israeli accusation has no credibility.
Greg Palast: My big fat Greek minister.
A Dutch meat-processing plant included horsemeat and putrid old beef in its shipments for five years, processing them outside normal working hours to keep the secret.
It used migrant workers who would communicate little with anyone around them.
The Senate seems to have no problems with Obama's billionaire bankster crony Pritzker.
I guess they suspend their usual obstructionist approach when it comes to actions that will benefit their masters.
If Americans do not condemn the absurd overreaction of the shutdown of Boston, it risks to become standard practice. That would crush Americans' human rights, while handing any terrorist or madman a lever to cause tremendous damage.
One single murder is being cited in the UK as the reason for massive surveillance.
Obama proposed steps to control drone attacks by law, and steps towards reducing the number of prisoners in Guantanamo.
When we know more, we will see if these are steps forward. However, they certainly don't go far enough. Any prisoners in Guantanamo that ought to be tried should have real trials, not military kangaroo courts.
US citizens: tell Big Oil to stop fighting the SEC's transparency requirements.
Lucky number 13? Maybe! Tomorrow "Luminosity" will get its thirteenth installment.
- Why we work together, and why we sometimes don't: In Free software, forking used to be seen as a really bad thing reserved for unfixable situations. These days it happens all the time. Duplication of effort was usually met with "Why?" rather than "Why not?", and typically reserved for the "beginner's application topic" (Was text editors, then irc (or mud!) clients, then media players, ..) Have we forgotten culturally the benefits of working together? Have new priorities shifted the playing field? When does it make sense to I'll try to make the case for less diversity than we have now, or at least a more responsible investment of effort.
- Open Build Service: We'll be looking at one of the coolest tools out there for people building software, images and operating system distributions: Open Build Service. We'll look at how it works, how it can be extended and at some self-hosting options.
- Q&A: If you have a burning question to ask, do so in the comments here or on G+ and I'll do my best to get to it in the show. Or you can ask live on irc ...
- It will be the last feature release in the 4.x series of Plasma Workspaces. Feature development will switch fully to the Qt5 and KDE Frameworks 5 based Plasma Workspaces 2.
- We will be providing stabilization releases (bug fixes, translation improvements, etc.) for two years for the 4.11 release of KDE Plasma Workspaces.
This does not effect, in any way, anything other than the code currently in the kde-workspace repository. Applications are not affected, kdelibs and kderuntime will continue on as they currently are (with kdelibs in a feature freeze of its own already). I fully expect there to be a 4.12 and likely a 4.13 release of the applications, and how long that goes on will be up to the application developers and release team.With that out of the way, some details!
Long Term Release
Decoupling the Software Compilation (Somewhat)
Shortening the Wait for Plasma Workspaces 2
How We Arrived At This Decision
I'm pleased to announce the release of the second edition of Linux System Programming, my guide to system programming on Linux.
I updated the entire book to reflect new interfaces and behavior in the latest versions of the Linux kernel, glibc, and gcc—3.9, 2.17, and 4.8, respectively—as well as giving the text a universal overhaul with even more examples and interesting anecdotes.
What I am most excited about, however, is an all-new chapter on threading. I cover the basics of Pthreads, of course, but the meat of the chapter is a discussion on threading design and patterns in Linux. Should you use event-driven or thread-per-connection as your threading model? How do Linux's threading solutions scale? What are the costs of and alternatives to threading? How can you mitigate the risk of races? And other such fun topics.
Chapters: Introduction & Essential Concepts, File I/O, Buffered I/O, Advanced File I/O, Process Management, Advanced Process Management, Threading, File & Directory Management, Memory Management, Signals, Time.
The paperback format of the book ships on June 4th. Preorder your copy today:
- Amazon
- Barnes & Noble
- Directly from O'Reilly
The ebook version is available today:
- Amazon Kindle
- Directly from O'Reilly (DRM free!)
A few years ago, I gave a history of the 2.6.32 stable kernel, and mentioned the previous stable kernels as well. I'd like to apologize for not acknowledging the work of Adrian Bunk in maintaining the 2.6.16 stable kernel for 2 years after I gave up on it, allowing it to be used by many people for a very long time.
I've updated the previous post with this information in it at the bottom, for the archives. Again, many apologies, I never meant to ignore the work of this developer.
Hopefully we can have the final late next week, but we might end up doing another release candidate. Please help testing the rc2 early to make sure you can have a solid release.
There are numerous little fixes, new features and enhancements that cannot be covered in a single article, so I'll only highlight some selected big-picture changes here. For the full list of changes, please refer to the draft Release Notes.
Preparation for 2.0
A lot of work went into preparing the users for 2.0 release that will come sometime next year, which promises large backward-incompatible UI changes:- "git push" that does not say what to push from the command line will not use the "matching" semantics in Git 2.0 (it will use "simple", which pushes your current branch to the branch of the same name only when you have forked from it previously; e.g. "git push origin" done while you are on your "topic" branch that was previously created with "git checkout -t -b topic origin/topic" will push your "topic" branch to origin).
This default change will hurt old-timers who are used to the traditional "matching" (if you have branches A, B and C, and of the other side has branches A and C, then your branches A and C will update their branches A and C, respectively), and they can use "push.default" configuration variable to keep the traditional behaviour. I.e.
$ git config push.default matching
Recent releases since 1.8.0 has been issuing warnings when you do not have any push.default configuration set, and this release continues to do so.
- "git add -u" and "git add -A" that is run inside a subdirectory without any other argument to specify what to add will operate on the entire working tree in Git 2.0, so that the behaviour will be more consistent with "git commit -a" (e.g. "edit file && cd subdir && git commit -a" will commit the change to the file you just edited which is outside the directory you ran "git commit" in).
Users can say "git add -u ." and "git add -A ." (the "dot" means "the current directory") to limit the operation to the subdirectory the command is run in with the traditional versions of Git (and this will stay the same in Git 2.0 or later), so there will be no configuration variable to change the default.
The 1.8.3 and later releases do not yet change the behaviour until Git 2.0, and limit these operations to the current subdirectory, but they do notice when you have changes outside your current subdirectory and warn, saying that if you were to type the same command to Git 2.0, you would be adding those other files to your index, and encourages you to learn to add that explicit "dot" if you mean to add changed or all files in the current subdirectory only.
- "git add path" has traditionally been a no-op for removed files (e.g. "rm -f dir/file && git add dir" does not record the removal of dir/file to the index), but Git 2.0 will notice and record removals, too.
The 1.8.3 and later releases do not yet change the behaviour until Git 2.0, but they do notice when you have removed files that match the path and warn, saying that if you were to type the same command to Git 2.0, you would be recording their removal, and encourages you to learn to use the --ignore-removal option if you mean to only add modified or new files to the index.
Tightening of command line verification
Many of them have been updated to detect and die on such errors.
Helping our friends at Emacs land
A beginning of a better triangular workflow support
- to have your own repository and push your work there while pulling from your upstream to keep up to date, or
- to have a central repository where everybody pushes to and pulls from.
$ git clone git://example.com/frotz.git frotz $ cd frotz $ git remote add publish ssh://myhost.com/myfrotz.git $ git config remote.pushdefault publishAfter this, you can say "git push" and the push does not attempt to push to your origin (i.e. git://example.com/frotz.git) but to your publish remote (i.e. ssh://myhost.com/myfrotz.git) because of the last configuration.
There are two versions:
Still, this revision does not add that much new content:
- Section 2.2.2. Bond stereochemistry (just refers to Chapter 3)
- Chapter 3. Stereochemistry
- Chapter 19. Chemitry Toolkit Rosetta
- Section 21.3.2. Grabbing dependencies (for Groovy)
The start of the stereochemistry chapter is interesting, explaining wedge bonds and the ITetrahedralChirality interface, but obviously I have to add the IDoubleBondStereochemistry will have to follow soon.
The first words of Chapter 19 look like what I tumblred earlier today (yes, I have an introductory chapter upcoming but not ready yet, causing the chapter numbering to differ):
Congratulations, Adobe, on your impending move from selling Photoshop and other boring old standalone applications that people only had to pay for once to a ‘Creative Cloud’ subscription service that will charge users by the month and hold their critical data hostage against those bills. This bold move to extract more revenue from customers in exchange for new ‘services’ that they neither want nor need puts you at the forefront of strategic thinking by proprietary software companies in the 21st century!
It’s genius, I say, genius. Well, except for the part where your customers are in open revolt, 5000 of them signing a petition and many others threatening to bail out to open-source competitors such as GIMP.
Fifteen years ago I pointed out in The Cathedral and the Bazaar and it sequels that buying proprietary software puts you at the wrong end of a power relationship with its vendor. And that this relationship will almost always evolve in the direction of more control by the vendor, more rent extraction from your wallet, and harder lock-in. Adobe’s move illustrates this dynamic perfectly.
But the response from its customer base highlights something else that has happened in those 15 years; open-source applications like the GIMP, and the open-source operating systems they run on, actually offer users a practical way out of these increasingly abusive relationships. Adobe’s customers aren’t being shy about pointing this out, and the company is going to feel heat that it wouldn’t have before 1998.
It’s not clear which side will back down in this particular confrontation. But the underlying trend curves are obvious; even if Adobe wins this time, sooner or later the continuing increases in the rent Adobe needs to claw out of its customers are going to exceed the customers’ transition costs to get out of Adobe’s jail.
The problem is fundamental; one-time purchase payments can’t cover unbounded downstream support and development costs. They can only even appear sufficient when your market is expanding rapidly and you can always use today’s new revenue to cover support costs from last year’s sales. This stops working when your markets near saturation; you have to somehow move customers to a subscription model to survive.
But doing that doesn’t solve an even more fundamental problem, which is that the stock market doesn’t actually reward constant returns any more; it wants an expectation of rising ones in order to beat the net-present-value discount curve. Thus, in a near-saturated market, the amount of rent you extract per customer has to perpetually increase.
But what can’t go on forever won’t. Eventually you’ll have to squeeze your customers so hard that they bolt. This may be happening to Adobe now, or it could take a few more turns of the screw. But it will happen. And as with Adobe, so with all other proprietary software.
Blogging will be limited for the next week.
I’ve received several requests for posts on a bunch of meaty topic, including (a) Adobe’s Creative Cloud move, (b) The Defence Distributed takedown notice, (b) the utility of power-projection navies, (d) current state of the terror war, and others. I won’t get to all of these anytime soon, because I’m swamped with work and will be travelling today to an undisclosed city for a meeting I can’t talk about yet.
Sorry to go all international-man-of-nystery on everybody but all will be revealed later this year. It will have been worth the wait.
This patch does not have a killer fix, but some things of interest. One patch updated the InChI to structure algorithm to also set atomic numbers for atoms, a patch that ensures the "C" and "C" are isomorphic (one of this use cases for which the algorithm was never written to work), hydrogen isotope reading from MDL molfiles, and passing of uncertain double bond stereochemistry to the InChI generator.
In all cases, users of CDK 1.4.x versions are recommended to upgrade to this latest stable version.
The changes
- Added a missing dependency 6ee0f0a
- setting unspecified bonds when generating and InChI 631281a
- unit test for bug1295 724366e
- Bumped the copyright year to 2013 22ff5a9
- Unit test to verify that wedge bond information is properly read ea8a316
- Unit tests for the expected behavior of bug #1294 c3a6452
- Removed redundant import (not found in class path) bfb2b1b
- Removed unused imports bc6e1a6
- Added citation for permutation method 1edc2d5
- Cleaned up documentation, reworded and added example usage. Update tutorial link to a site which has backed up the now missing web page. d76cac6
- Fixed proton isotope perception. 421345b
- replaced cast to implementation with a cast to the interface c273930
- Small patch for bug 3551478 71f40a9
- Added additional test that non matching symbols mismatch c532191
- non-null atomic numbers when reading from InChi [bug:1293] 3117f4c
- Test to ensure that the atom type name is returned with IAtomType.toString() 471a20c
As you can see below, this release has a patch by a new contributor, Magda Oprian.
8 Egon Willighagen
8 John May
1 Magda Oprian
1 Stephan Beisken
7 Egon Willighagen
4 John May