ackalker

I'm wondering why Microsoft didn't add the unique serial number requirement to its WHQL driver testing, allowing vendors who realize too late that their shipped devices don't have a unique serial number to add the "magic registry key" (for ignoring the serial number) to their next WHQL driver candidate.

How about this one?

mcoll - Modern API for python collections: https://github.com/nvbn/mcoll

Ergo: use a distribution like Arch Linux or Gentoo. Arch Linux has the advantage that you don't have to build everything from source yourself. Both have the advantage that the build scripts are easy to understand (Arch PKGBUILDs more so, IMHO).

In the end you will always arrive at a chicken and egg situation, you will ultimately need to trust the engineers who designed your CPU and chipset, the VLSI design software which they used, the developers who wrote the compiler and toolchain, the tools used to bootstrap it, external libraries, etc.

The world ultimately runs on trust, no matter how you slice it.

From README.md:

    M/o/Vfuscator 2.0 is a complete C compiler, and will be available soon.

Just be patient, or submit patches :-)

I'm filled with joy to see that PicoLisp runs on OpenWRT. I would love to see PilOS itself running on a wireless router, if only to be able to brag: "My router runs Lisp!" :-)

Atom runs as a Web app in Electron (formerly atom-shell), which is basically a stripped-down version of the Chromium browser combined with Node.js and some additions to ease interop between the Web app and the host OS.

Npm uses Web protocols (HTTP, maybe JSON-RPC) to communicate with repository servers.

This is not saying that there aren't any non-web applications using Node.js, just that web-related applications using Node.js are quite numerous and popular.

Personally I know of Node.js applications and libraries targeting robotics, computer vision, language analysis, neural networks and more. Like any powerful platform, much of this relies on the ability of Node.js to interface with external libraries, which it does using wrappers built with node-gyp.

> ... they don't have google's keys

Assumptions, assumptions.

Moments after hitting this article, I was 'greeted' by the most awful, full blast, in-my-face, nausea-inducing swinging pop-up begging me to sign up i've ever seen. Please take it down asap, thank you.

Just for the record: Arch does have testing and staging repositories for testing new versions of packages that may cause major breakage if they have bugs or packaging problems.

AFAIK new versions of glibc, other major libraries, systemd, Linux kernels, etc. are always kept in one of these testing repositories for a while to catch serious problems.

To help make Arch better, consider running one or more systems on [testing] (a chroot or VM will do) and reporting any problems you find.

Those are some very useful oneliners, thanks! :)

Please consider adding them to the Arch Wiki (if they're not already on it).

I believe an important reason why Arch is easier to maintain has to do with its minimal package customization:

Applications already have their own learning curve, custom packaging only adds to this. Just reading the documentation or googling for answers may not be enough, one also needs to understand how and why packagers have changed things to be different from upstream.

Personally, I prefer the Arch way of keeping package customization to the bare minimum. Combined with the very simple package format and powerful tools, Arch is a winner.

I'm wondering if that question was meant to be rhetorical or merely self-referential. :)

Cool stuff! I'm wondering: are there other fun things people have done with Git repositories? Things that come to mind are:

- Family trees, genealogy

- Electrical circuit schematics

- Storylines for books, movies, RPG

- Accounting, ledgers

- Jurisprudence

etc.

Have you watched the movie "Eagle Eye"? How about "WarGames: The Dead Code"? If not, please do. Both, in their own way, have some interesting points regarding the risks involved in using A.I. in warfare, as well as the reduction of complex social interactions to mere graph theory and statistics.

It is quite possible that the regex doesn't match anything useful. From the looks of it, I would say it was generated using a fuzzing tool, in much the same way as what lead to the discovery of the Shellshock vulnerability.

From the changelog:

    ** The preference

          do_braindead_shortcircuit_evaluation

       is now enabled by default.

Yup, that put a grin on my face that is going to stay there at least for the rest of the day.

Correction: for a small minority of those potentially interested, see my previous comment. For everyone else: welcome to the world of the hacking underdogs :)

Irony isn't lost on those of us who are not USian (that's 95.5% of the world's population, last I checked), some of whom may feel compelled to take their first steps into the world of hacking (monkeying around with IP anonymizers, proxies, VPNs and all that, or going straight for the inevitable torrent) just to be able to watch that pilot episode. Way to go, dudes!

Very interesting, but personally I would look for some kind of aesthetic beauty in an algorithm, not just a notorious history, before I would consider it "art".

Take this one for example: it is an implementation of the Quicksort algorithm in a programming language called Joy:

    DEFINE qsort ==
       [small]
       []
       [uncons [>] split]
       [enconcat]
       binrec.

For me, it has all the qualities of a programming haiku, poetry in code.

Reading the title, I was worried for a moment that I had clicked through a time portal. GIFs. Aren't they as old as CompuServe? Then I read the body text, thinking: "Do I know anyone who hasn't turned off GIF animation in their browser yet?"

Ah, okay, but that would imply that GitTorrent doesn't make any use of the swarming capability which makes BitTorrent special.

Not using swarming brings back all of the old problems of NAT traversal, asymmetric upload/download bandwidth, throttling, censorship etc.

The problem is not with deltas between revisions (i.e. the commits themselves) but with the Git packs spanning multiple revisions. At the time of a `git pull`, a user's repository can be at any revision between initial and latest. Who is going to seed (and keep seeding) packs for all of those possible revision intervals?

A very interesting idea, GitTorrent, but I have one question which comes to me whenever I read about a delta-based distribution scheme: who is going to generate and share all those deltas?

Some Linux distributions have experimented with delta-based package repositories, examples are deltup for Arch Linux and rpm-delta for RPM-based distros. Some of the known issues are:

- choosing the number and spacing between deltas. Fine-grained deltas require more storage space, coarse-grained deltas require more download bandwidth.

- retiring old deltas: periodically deleting all deltas older than a certain version, replacing them with the full package of that version. Again a trade-off between storage space and download bandwidth.

For Git repositories, this would roughly translate to:

- choosing the number, history spacing, and size of the Git packs per repository.

- retiring old Git packs: periodically deleting Git packs older than a particular revision, replacing them with a bare repository at that revision.

The economic context of copyright, in particular the current system of compensation based on royalties, is bad because it creates an unrealistic multiplier effect.

The classic example: for every loaf of bread a baker bakes, the variable costs (raw ingredients, fuel, labour) are approximately the same for each extra loaf baked, so his margin and profit per loaf don't magically increase by baking more.

Contrast this with someone creating a copyrighted work and receiving royalties per instance sold or performed. Here, increased volume does increase margin and profit per instance, because the real cost of labour the creator must put in to receive royalties on every new sale or performance tends to zero. (I'm discounting the cost of marketing etc., which in most cases has only a second-order effect and doesn't change the final result.) Add to this the income which copyright brokers receive from media distributors etc. without having any part in the creative process, and things become very unbalanced real quick.

The root cause of the problem is that it is extremely hard to put a realistic monetary value on the act of creating a copyrighted work, as it would have to take into account the real effort required to create it, as well as the total (mainly intangible) benefit to all who will ever get exposed to it.

It would be much better if the artist could make dealings directly with the audience, just like the baker does with his customers.

As Syd Barrett put it: "All middle men are bad."

I cannot help but say that this reminds me (an awful lot) of the Umbrella Corporation. Except for its involvement in bioengineering that is, but who knows what's yet to come.

The truth may yet turn out to not be that much stranger than fiction after all.

  New ideas go through stages of acceptance, both from 
  within and without. From within, the sequence moves from 
  “barely seeing” a pattern several times, then noting it but 
  not perceiving its “cosmic” significance, then using it 
  operationally in several areas, then comes a “grand 
  rotation” in which the pattern becomes the center of a 
  new way of thinking, and finally, it turns into the same 
  kind of inflexible religion that it originally broke away 
  from. From without, as Schopenhauer noted, the new idea 
  is first denounced as the work of the insane, in a few 
  years it is considered obvious and mundane, and finally 
  the original denouncers will claim to have invented it.

So true, sadly. I deeply regret that today, many people interviewing for programming jobs get grilled over their knowledge of this particular OO design pattern or that, while neither the interviewer nor the applicant may realize that some of these "patterns" are just dogmas invented to deal with particular language limitations of (older versions of) Java, and entirely different patterns (or even paradigms) are available if only one takes the time to look past the boundaries of one's preferred (or prescribed from above) programming language.

IMO, prospective programmers should be invited to show true creativity and insight, not to just queue up to create the (N+1)-th CORBA framework.

Structured programming, modules, OOP, FP, ever more elaborate type systems, whatever next new thing is going to be seen as the One True Way, I still believe that Socrates will have the last laugh (...or grin)...

http://en.wikipedia.org/wiki/Socratic_method

Too bad that for some reason in my browser (Chromium version 43.0.2357.65 (64-bit) on Arch Linux), HiDPI setup (which was added to Chromium very recently), the fonts look extremely blurry, giving me the irresistible urge to squeeze my eyelids to get things in focus. I experience no such blurriness with other web apps (whether using plain HTML/CSS, SVG, HTML5 Canvas, etc.).

Joy!

After the speedy download from Github (which weighs in at more than 40 times the capacity of the hard drive which held my first *nix system), I was able to locate a patch I submitted to FreeBSD in less than 12 seconds from running gitk on the file in question, thanks to the wonderful world of Git.

I shudder at the thought of having to manage all of this using CVS, pulling changes using CVSup or whatnot.

Thanks for sharing! :-)

Just how does using `git init`, `git add`, `git commit`, `git push`, `git merge`, `git pull` force one to know Git's implementation details?

Even thinking of Git as a security camera watching your shop (working tree), a VCR (record, forward, rewind history), a videotape copier (branching, pushing) and video editor (pulling, merging) wouldn't be too far off the mark, without the need for any reference to Git's inner workings.

Sure, a lot of Git talk mentions SHAs, trees, blobs, etc., but they could just as well have been brownies, blurfls, gizmos or whatever, as long as the practical context in which one needs these things is clear. Branches, tags and remotes are still the most useful top-level concepts, with no need for knowing their implementation details.

Only when one needs to do really low-level stuff like efficient import/export, history rewriting (ugh) etc. does one need to know a little more about how Git works. Many people have used Git for years without knowing anything about the plumbing beneath its porcelain.

> [...] will this start a race of scanning materials(i.e. combinatorial chemistry) to find catalysts ?

It will be like the race to find high-temperature superconductors all over again :-)