rquirk

In my project I use "env GOPATH=$PWD go ..." in the makefile, that way it all goes in the current directory. There's probably some good reason this is a bad idea, but go is kinda funky anyway so I make up my own best practices :-)

Straight razors are pretty popular still in shaving forums.

The IoM isn't part of the EU or the UK. As a Manxman living in Europe, I'm fortunate that my mother's side of the family is English or I'd have more trouble with work permits and whatnot. I haven't been able to exchange my Manx driving licence for a Spanish one, for example, since it isn't recognised.

As for taxes, people on Mann get screwed over on prices - everything from groceries to petrol is more expensive than the north of England since it has to be shipped in. The tax breaks for residents are less than for corporations too, without the corporate breaks I think there would be less work there in general. Might get rid of the southern English bankers that all moved there in the 2000s if they removed so many incentives so it wouldn't be a complete loss ;-)

This isn't really a Docker thing though, is it? It is talking about the case of a program that includes its dependencies in its own source code tree. I think docker-ized programs would still link against e.g. the system libssl rather than ship a copy of an ssl library with a program's source. Another term sometimes used is "vendoring".

A lot of Java programs ship jar files in their source tarballs, it has traditionally been a lot of work for Debian devs to pick these apart. Similarly, many "things" (programs or web services) that use javascript libraries often ship minified versions of common stuff like jquery rather than use the system version. It's quite a mess. I think a lot of it stems from the fact that traditionally these sorts of libraries (jars, javascript) have not been well packaged or even packaged at all. The program authors are making life easier for the majority by shipping all the deps together. It's not good for distros, but I can see the advantage.

I think subversion has a nice work around for this - they include a script to download the dependencies if you need them, otherwise the default is to link vs system deps.

Doesn't work on Xfce either. On a virtual terminal thingy (ctrl-alt-f1) it shows a grey background with white text. I suspect blink is only implemented on the Mac's terminal, not in Linux-land.

Looks like it was people clicking google code's "export to github" feature before you got round to doing it ;-)

I wouldn't worry about it - the clones will probably not go anywhere and just die off, abandoned. True they don't link back to your now-canonical repo. As viraptor said, maybe contact the users. They might prefer to fork your repo now it's on github.

Will this also affect Firefox for Android?

Mozilla currently don't provide a dev build for Android, just regular and beta versions https://play.google.com/store/apps/developer?id=Mozilla

The security problem that this "fixes" is not really an issue on Android due to Android's own app sandboxing, so maybe the Android build will allow unsigned extensions? It's not mentioned in the FAQ.

The FlatBuffers repo on github continues a couple of "meta-trends" I've noticed in recent Google projects. https://github.com/google/flatbuffers

First, it uses CMake to build - for a long time Google projects had seemed pretty anti-CMake (for example using gyp, plain Makefiles or autotools) so it's nice to see them using CMake. IMO it's the best build tool, though all build tools generate various levels of hate :-)

Second it's another Google project that generates good developer docs from source code using doxygen and markdown. These docs look good on github directly (https://github.com/google/flatbuffers/tree/master/docs/sourc...) as they are markdown, and even better on the dedicated site where they have custom css.

If I were to write a C++ library, I'd definitely copy these 2 approaches.

You haven't broken the podcast RSS feed, thank you. Another large podcast network recently did a redesign and broke all of their feeds, apparently on purpose. Crazy.

However, the podcast feed is impossible to find now if you didn't have it before. Previously I think it was on every podcast post as an RSS link. Now the individual tag RSS links all point to the main feed, rather than to a per-tag feed.

e.g. http://blog.stackoverflow.com/category/podcasts/feed/ still works if you know it, but going to https://blog.stackexchange.com/tags/podcasts/ gives you an RSS link to just "/feed/".

This is probably not a good place for bug reports :-S

It's sounds like how Gerrit works, from a user's POV at least. You can push to a repo that you don't really have write permission to, and it goes into Gerrit. The post-push scripts create a sort of branch-tag thingy from master with your commits on, and so when the Gerrit review passes ("pull request accepted") the change is merged/rebased/cherry-picked onto the latest stuff. If the review is rejected then the temporary branch is dropped and that's that. Since all the reviews items in gerrit are just git references, you can use all the usual git commands on them (pull or fetch it, then merge) if you know the gerrit tag, but since they are strange branchless things they are not pulled down by default in a normal clone.

It's harder to explain than to use actually. Ah! there's a bit of a wrinkle with gerrit in that it uses a local hook to insert an ID into commits, so rebasing or cherry picking knows which commit to reference. But that might be optional, it'd be like cherry-picking a pull request, I think github doesn't close the original in that case? Not sure on that though.

Yes, I do this too. Incredibly, a lot of airports only have hot water in the bathrooms. Or sinks designed in such a way that a bottle can hardly be filled at all.

While we're at it, can we be allowed to carry bottles of water through security? At least in Europe, having to pay 3€ for a 50cl bottle of water after passing through the checks is clearly just a money-making scheme and has nothing to do with stopping terrorism.

I dunno... anecdata here, but my kids have quite a few sets - Batman, Ninja Turtles, Star Wars as well as some brick boxes and Lego City stuff - and they mixed them all together and now build whatever they fancy all the time. I was horrified actually, they don't care. In fact when I tried to build up a mini Millenium Falcon that's hidden in there I was told to clear off.

The new sets do have a few weird "only for that set" bricks, like batman helicopter blades or weird rubber Jedi hair pieces, but generally everything still fits together with everything else. I will say that there does seem to be a high percentage of small round 1x1 transparent studs. Every set seems to come with loads of 'em.

It's why I love the Nintendo DS and its successor the 3DS - any game can be paused just by closing the lid! In this low-power mode it can last for many hours, possibly days.

Does this work for you? https://groups.google.com/forum/?_escaped_fragment_=forum/tm...

It works here with Firefox+noscript, but in w3m it messes up when you read an article and forces you to a "need JS" page. I might have added some other hack somewhere in FFx ages ago to get groups working that I've forgotten about.

Wow, that's quite a surprise. I just checked the terms you quoted - https://play.google.com/about/developer-content-policy.html - and of course you're absolutely right.

I can see why Google specify this since a store filled with spammy apps wrapping popular sites would be bad for everyone. But this puts the kibosh on privacy-focused apps like Tinfoil for Facebook or the Twitter equivalent, and bloat-reducing apps like the OP's. I imagine that these have yet to be suspended simply because nobody at Google has noticed them.

Unfortunately there is a flaw in this design of Firefox OS. By baking the rendering engine into the core OS, it is impossible to upgrade the browser separately from the rest of the system. So updating Firefox (the browser) requires a firmware update, and we all know how terrible manufacturers and carriers are at pushing out updates. The result is that all Firefox OS devices currently available are running old and insecure browsers.

Here is an explanation from the mailing list, so at least Mozilla are aware of the issue. https://groups.google.com/forum/?_escaped_fragment_=msg/mozi...

> The reason for this is because gecko determines how the user interface > (implemented in the gaia layer) actually behaves. There may be bugs in future > versions of gecko that break parts of the UI, and the carriers/manufacturers > understandably don't want to just push these updates without verifying them > first.

Ah, bummer. I tested in csh too but not fish.

There's just one scenario: a completely absent #! line.

It's an easy fix, just add the line, otherwise 0755 scripts with no #! do execute using the current shell.

FWIW I had the same good support experience regarding Nexus tablet failures. The cynical side of me thinks that this is one reason they are rumored to be canning the Nexus tablet line. Support costs are too high.

Right, I'm sure you could do the same thing with grep and a classic /var/log/messages - in fact there's probably something to do this already. Or you'd find a gz from the day in question and read all of it. Just happened that I'd recently read the man page for journald and that was something I recalled.

> "give me 10 hours starting from last Friday 2am"

journalctl --since="$(date -d'last friday 2am' '+%F %X')" --until="$(date -d'last friday 2am + 10 hours' '+%F %X')"

Now I'm no systemd apologist but maybe some of the hate towards systemd, journald and pals is unwarranted. If one gives these newer tools a chance, they actually have some nice features. Despite the Internet's opinion, seems like they were not actually created to make Linux users' lives difficult.

If binary logs turn out to be the wrong technological decision, I'm sure we'll figure that out and change over to text logs again. All it would take is a few key savvy users losing their logs to journald corruption and the change in the wider "ecosystem" would be made. But if all goes well... then what's to complain about? :-D

Have you tried using the logging module? Might be overkill for really small scripts as it requires a few lines to set up, but even the tiniest tool ends up requiring print-debugging at some point. With logging it works the same in 2/3, you can leave all the debugging statements in, and if a library also uses it then you get additional debug output from that too. Add a "debug" command line flag to pass when something goes wrong down the road (to change the default log level), and you don't have to add/remove statements for debugging.

For a vim extension - I use snipMate http://www.vim.org/scripts/script.php?script_id=2540 It's a bit on the dead side but works great as-is. ifmain followed by the expander key (shift-tab in my case) expands to the if __name__ ... idiom. You could add your own "p" snippet that expanded to print() in python code.

I have a small script in my ~/bin that pipes `info --subnodes "$@"` into less. That way I don't have to remember all the keys, and the whole output is like a big man page. Although on Debian and Ubuntu the info pages are usually not available by default anyway due to the "GNU docs are non-free"-decision Debian made a few years ago.

I disagree, and think they've done a great job. The CMake devs have always been really responsive to bigish projects that find CMake to be almost-but-not-quite good enough for their project, adding in missing autotools features or other semi-commonly used bits and bobs.

They manage to keep up with all the churn in the world of compiled software, whereas it would be so easy to let a tool like CMake bitrot. Old mistakes have sensible deprecation policies too, so they have managed to avoid the accumulation of cruft that could have brought it to a standstill.

You can speed it up somewhat by tweaking ~/.gradle/gradle.properties and adding org.gradle.daemon=true and org.gradle.parallel=true. That way at least it doesn't have to re-read all the build files each time and will run some parts in parallel.

The benefit wrt the old Ant-based build is the way it lets you specify 3rd party dependencies. Being able to just add in say Timber, ButterKnife and Guava with a few lines of config, rather than downloading the jars, faffing with paths, making sure the pre-processing bits are in place, etc, is really a big benefit. Maybe Maven would have been a more sensible choice, since Gradle/Groovy seems pretty niche and not really used that much outside Android.

Right, I'll try not to be so grouchy :-D

Some reasons are the bloat, the possibility of "accidental" forks when a non-upstream version is compiled and checked-in binary-only, crufty old versions hanging around, and security problems. It adds extra work for downstream packagers having to pick it apart for distros.

Bundling gets particularly bloaty for git repos, since the history is always included in each clone. For perforce or SVN it doesn't matter so much as you only get the latest version of everything. In git each time there's a dependency update, it will pretty much add the size of the new jar to the .git directory. Over time it's going to grow huge. If at a later date the repository owner decides on a new policy where the third party files are not bundled, then even removing the directory from the current head doesn't shrink the repo size.

There are binaries in there for Mac, Linux and Windows (.exe file at least). You either need one or the other, not all at the same time.

This sort of thing is fine for proprietary software used in a controlled environment, but for open source it looks kludgy.

An alternative could be to have a "dependencies" repository that would be shallow-cloned as needed. At least that way the source code repo only would have source in it, not jars or executables. It'd ensure separation was enforced and you could still track requirements per version or change the policy later.

Right... but this will be an anchor on adoption. I can see why e.g. the Android build system does the same thing since it's all off in its own world anyway. I doubt you'd be popular with Linux distro packagers if you required bazel for some C library.

What is this lameness? https://github.com/google/bazel/tree/master/third_party - why not use gradle repos to download jars with known hashes? Sticking all those jars in the git repo is just... well, I expected better from Google.

Here are a few: vim, waf, ttrss-reader-fork, gperftools, include-what-you-use, googletest and googlemock. All have had commits in the last few weeks, some in the last day or two.