Perhaps you'll like this, then: https://github.com/ustuehler/git-cvs
475 karma · joined July 23, 2014
$ time cvs -d anoncvs@anoncvs1.ca.openbsd.org:/cvs export -rHEAD src/sys/kern/kern_fork.c
U src/sys/kern/kern_fork.c
0m2.73s real 0m0.06s user 0m0.04s system(pastebin since HN wouldn't let me post the full link list as a comment)
That's not true. OpenBSD developers want this. There are several ideas floating around about making the kernel cache wifi passwords, scan and re-connect automatically when it lost link to the AP. This topic keeps coming up during hackathons.
For various reasons it's not as easy to do as one might expect.
The net80211 layer and wifi device drivers don't keep track of link state to the AP at present. This would need to be implemented first. It is essentially client-side roaming support. One way of doing this is to count missed beacons and assume the AP is out of range if no beacons have been seen for a while. Some devices provide such counters in hardware, some don't. The biggest part of the challenge is to make this work seamlessly with _every_ driver.
Then there's a risk of feature bloat. Add too much automation and you end up with something opaque like network manager which just pisses many people off. Add too little automation and you don't cover many use cases. And networking is not just about wifi, it's at least about ethernet and VPN as well. Some tools already exist to handle aspects of this (e.g. ifstated(8), trunk(4), interface priorities managed with ifconfig(8), a ton of ipsec tooling), and should be properly integrated in the design.
Another question is how to integrate with desktop wireless tools that come from Linux (e.g. wifi network pop-up menus for KDE4 and Gnome3) which usually require a backend using Linux-specific ioctls or dbus/NetworkManager/systemd APIs to function. But seamless integration with desktops would be outright awesome and make the system much easier to use for non-technical users.
There's probably a couple of gsoc projects worth of work in this. If someone is seriously interested ("no talk without diffs attached" kind of serious) in pursuing this I might be available to act as a mentor.
One reason is that humans need affordable and clean water to drink. ISDS cases have caused water quality and price regulations to be disregarded in Germany and Argentina.
Source: http://www.theguardian.com/business/2015/jun/10/obscure-lega...
Just like Austin != Texas
Forking nginx was actually discussed when a proposed nginx update diff was too large for proper review. Tons of complex regex parsing code was added with nobody willing to go through it all in detail.
The forking option was quickly dismissed. The tipping point happened when someone (reyk?) pointed out that relayd had most of the guts of a complete web server anyway, including OpenBSD-style privsep which has to be bolted on to virtually all software imported from elsewhere, including nginx. It took about a week from that discussion happening to having a relayd-based functional and peer-reviewed web server in base (+ a couple of months of shaking out a few bugs and adding minor features).
The Wee Free Men and Dodger are also nice to read. They focus a bit less on humour, being geared a little more towards children. Don't expect to laugh all the time. But the settings of these stories are magical.
The ASF has a strict policy of self-hosting. So git repos are now mirrored to github from ASF intrastructure, for the github fans who initially suggested the reverse (ignoring obvious problems such as ASF having no influence over what happens at github).
You can set an svn:needs-lock property on binaries. It is not a local option, it applies to everyone using the repository. For extra convience, use svn:auto-props (acts recursively) to set it by default on new files which match a particular filename pattern (e.g. match on file name extension). http://subversion.apache.org/docs/release-notes/1.8.html#rep...
EDIT: That said, I agree that some types of binary files really have no place in SVN repositories. One example are release artifacts, as stored e.g. in Maven repositories.
Bug reports to users@subversion.apache.org please. Or it didn't happen ;-)
This tends to happen especially in shops that migrate off process-heavy monsters like clearcase and MKS. These tools do a lot more than just version control, and no open source version control system by itself matches what users of these systems expect. You have to throw at least an issue tracker and a good build tool into the mix as well.
Take a good look at the ecosystem of your open source project. Does it have a large user community? Are there companies involved in funding some of its developers? Will the project still be alive in a couple of years?
If you contribute to widely used open source projects you should be able to find paid jobs doing consulting (troubleshooting bugs and other problems, helping companies who are transitioning to using the software), training users who rely on your project to do their job (this might involve a good amount of travelling), and coding (but to a lesser degree). Coding activities are often taken for granted even by commercial users since "it's free software" as in "saving costs". I am rarely being paid for coding directly, and mostly work on code during off peak periods where not much consulting/support/training is going on.
Unless you start a project of your own, there's a non-trivial amount of time to invest before you become enough of an expert in a project to be taken seriously by potential clients. I was lucky enough to be on paid student job to do just that for several years and now I'm freelancing too (URL to my offering can be found on my HN user page).
Showing a strong and productive presence in user support forums will also help raising your profile, but again is a lot of time invested up front.
If you end up persuing paid open source work in earnest I'd be interested to hear how you're getting on. Feel free to contact me any time.
Good luck!
And now name a wifi chipset that isn't made by one of these companies. :-)
It's awesome that Linux has achieved this kind of support. But this is a luxury. Don't take it for granted. It took a long time and a lot of energy to get there. These companies are still keeping hardware docs under NDAs so it is very hard for other open source systems to compete fairly.
Get the vendors to make wifi firmware freely redistributable (or even better, fully open source + build instructions) and it will work out of the box.
Your ethernet chip is bce(4) which really needs this fix if you have more than 1GB of RAM in the machine: http://marc.info/?l=openbsd-bugs&m=142195923213919&w=2
Alternatively install a -current snapshot. bce(4) should just work there.
Do you remember what Linux wifi support was like between 2000 and 2010? Wifi drivers are pretty hard to write and there are virtually no docs for any of the available hardware. Linux (and FreeBSD, too) have better wifi support nowadays because vendors have finally started writing drivers for those systems. Look at the email addresses of authors in copyright statements of Linux drivers for Atheros, Broadcom, and Intel cards, for example, and you'll see that this driver code was written in-house by vendors. OpenBSD doesn't get that level of support from vendors.
I did spend some time to make toad work with xfce for the 5.6 release (resulting in reports such as https://bugzilla.gnome.org/show_bug.cgi?id=724916). If toad is really broken in 5.6 I'd really like to know how and why.
If these commits were used to adjust version numbers in source files, the following trick should eliminate them: Check out the release branch into a working copy, adjust the version numbers in the working copy, and then copy the working copy to the tag's URL (as in: cd working-copy; svn copy . ^/tags/1.0)
If this was a maven project: The maven release plugin is doing this wrong and performs 3 commits to an SVN repository per release...