git annex metadata gui
I always wanted this to exist. So awesome that someone (not me) has gone and built it.
git-annex's metadata facilities have been somewhat of a hidden feature for power users. It will be interesting if that gets wider use. The metadata is synced as part of the git repo, and automatically merged.
Claes Wallin (韋嘉誠) shared this.
hole in one
\o/ git-annex get over tor worked the first time I tried it
(After 2+ weeks developing the feature)
the dreams of the 90 are alive in my xmonad
- wikipedia via telnet
- metafilter via gopher
- olduse.net via nntp with special NSA appearance
"Until we can be confident that these strings will never be used as a weapon, their presence probably needs to become a Debian policy violation." -- phil hands http://joeyh.name/blog/entry/trademark_nonsense/#comment-5ebe49ce6d9df9703a9ef54502b3dc04
"whenever you are in a situation like that when people have given so much to you, one of the first instincts is like what can I do for you, what can I give back?"
Ian, you helped so many of us find our answers to that question.
The Internet of Code
If you don't know haskell or lambda calculus, skip 19:30 for the start of the payoff.
Gergely Nagy likes this.
Saw this talk & was dying to see the source. http://files.luite.com/hs15/ .. which is this haskell: https://raw.githubusercontent.com/luite/hs15-talk/master/hs15.markdown
Using lists as fake value boxes in python because python doesn't know how to lexical scope
Gergely Nagy likes this.Show all 6 repliesPython 3 has the 'nonlocal' keyword that does exactly what you want (if you inserted "nonlocal x" as the first line of _func(), it would do the right thing)... but, well, you don't get it unless you switch to Python 3.
A fantastic little Emacs Lisp poem by RMS:
In days long ago,
When clocks were so slow,
These basic keystrokes
Took too long for folks,
Unless they were writ
In C code to flit.
Today that's not so,
In Lisp they can go.
Basic git hygiene at this point probably includes only merging git commits from others that are gpg signed (as well as gpg signing as many commits yourself as you can without going mad at the password prompts).
Unfortunately, tooling doesn't make this easy, and some things like git format-patch are actively unhelpful by not preserving gpg signatures.Also, note that signed git tags are only a signature of the sha1, so cannot be used to detect a collision attack.
Checking git commit signatures can detect a collision attack. Of course, that checking is also not enabled by default, and there's not yet a config to change that.
Unacceptable excuses for bad behaviour in free software development:
Show all 5 replies> because that's what got them where they are so far.
- Linus and other kernel developers do it.
- You have self-diagnosed as having Asperger's.
- You value code quality over other people's feelings.
- You get angry a lot.
- You think other people are just wrong about everything.
- You thought of a funny insult.
- You're uneasy having people in the project who're unlike you.
They could have gotten where they are so far in spite of (rather than because of) the behaviors. There's always the chance that several people saying "I'm not going to take this anymore" around the same time will shift momentum away from a previously-successful project or organization.
@lnxwalt That's true, the person with the bad behaviour has typically proved they can make the grade, give the company what they want, work hard, demonstrate their talents. At this point they use their value as a kind of credit system to get away with behaviour that others don't seem to get away with.
Claes Wallin (韋嘉誠) likes this.
haskell with a sailboat chaser
then and now http://joeyh.name/blog/entry/then_and_now/
On extensibility of Microformats
Once again, Amy Guy (member of the W3C Social Working Group and probably the person with sharpest analytical eye in the group) has done a fantastic breakdown of a SocialWG-related topic. This one is on the extensibility of Microformats. This is a topic of much back and forth, particularly between "Linked Data" people and "Microformats" people, and maybe Amy's post can reduce a lot of unnecessary cycling. Particularly this point is insightful:
Example debate 4
- LD: Microformats is not extensible (meaning: I can't just add my own terms and have everyone know how to use them).
- MF: Microformats is extensible (meaning: parsers are vocabulary agnostic).
... LD is talking about the vocabulary (semantics). MF is replying about the syntax. I think that's why this debate goes round in circles. I hope that clarifies something for both sides.
Way to go, Amy!
If your project uses NPM (or its dependencies do), it probably can't be packaged by distros
Yesterday two things happened in #mediagoblin:
- The second thing that happened was I expressed in frustration how much I dislike NPM, towards which a friend in the channel exclaimed surprise. NPM is their favorite language package manager, how could I dislike it?
- On a traditional distribution like Debian or Fedora, this is an impossible situation, since traditional distributions cannot easily accomodate multiple versions of the same package.
- Even in fancy-pants new-age functional distros like NixOS or GuixSD where such a thing is possible, managing that dependency chain is mind-bendingly complex, and almost nobody is going to want to do it.
- The culture of npm is to break things down into many super tiny packages, which is fine in npm-land, but exhaustingly complex for those trying to package free software distributions.
- This also introduces potentially serious security issues: even if you are using all the latest versions of your dependencies, your dependencies' dependencies may be massively out of date, and it's hard to keep track of that. You may be presenting your users with dangerous security vulnerabilities and may never notice.
Despite all this, npm is popular with many of its end users. It's easy to understand why: the decisions made above make it very easy to get up and running with npm, though not necessarily easy to maintain keeping things up to date in the long run, and when pushing out deployments while eschewing the system package manager, things appear to "just work". And if you're working for a startup which is using NPM for its proprietary "top level product" which only goes out to its own personal sever deployments, maybe this doesn't matter.
For those of us concerned with building applications we want to push to end users for advancing network freedom though, this might be a serious problem.
(The similarity to this problem to "application-container systems as static compiling on a distro-sized level" is left as an exercise for the reader!)
The same friend previously referenced from #mediagoblin brought up that this is a "fix the distros" vs "fix the package managers" discussion (well, kind of, it also might be "fix the packages"). But I think there may be another way forward that is kind of both related to functional package managers: if people were developing using nix/guix they could use the "universal virtualenv" type features each provide (eg "guix environment", and I forget what the nix equiv is) to do their development, at which point the package is probably also passing the test of being reasonably generally packageable / deployable as well.
It's also true that NixOS/GuixSD are more likely to be able to survive packaging applications designed with npm in mind than more traditional distros like Debian / Fedora can... since they are building derivatives which are purely based on their inputs, multiple versions of dependencies can be handled, it's just a bit of a pain in the butt.
But I think a package built with Nix/Guix as a starting point for a development environment is less likely to end up in the state of an NPM package which may potentially have significantly old dependencies in its tree, as it's fairly easy to identify and keep things up to date, and "sticking with old versions" is not considered a feature or something that happens as much without being noticed.
That said, I still value Debian / Fedora, and I would like modern applications to be able to be installed on them!