elehack

I read this book in college and was captivated. Not terribly long, but fascinating for learning how the insides of our tools work (or could work better).

> A big one for me is keyboard input: at one point, I could use the Super key for whatever I liked, and I could easily set the right Alt key to be a Compose key. Now, there is no reclaiming the Super key from hard-coded shortcuts (Unity is even worse about this!), and the Compose key is outright missing from the keyboard settings menu.

Compose key is moved. To a non-obvious spot (if you're used to its historic location).

Settings → Keyboard → Shortcuts, the ‘Typing’ section. There's ‘Compose key’, which lets you set the compose key.

It's also in a more traditional form in Gnome Tweak Tool.

The lack of documented software that used them to enable useful (to me) functionality.

I was using some of them, such as kvm for my virtualization and lvm for disk management. But systemd still had a substantial 'oh, wow, Linux lets process management be this easy and powerful?' factor, showing me something new that I hadn't seen in my use of any other system (FreeBSD, OpenBSD, Windows, a touch of Mac).

Not quite.

I'm saying that systemd makes the Linux kernel's feature set and capabilities visibly usable from user-space. For (nearly) the first time, it feels like it matters that I'm using Linux.

Linux is still Linux without systemd, it just doesn't provide as much benefit (aside from device support and compatibility) over, say, FreeBSD without software that takes advantage of its feature set.

> However, in my mind it has made several awesome things possible. My boot time got dramatically shorter when I adopted it thanks to parallelization. Besides, daemons have now simple and robust service definitions. Sys V had become a mess!

Writing daemon startup files was somehting I always dreaded, and never really did well.

Before systemd, if I needed to run services I'd try to use daemontools (for auto-restart, and logging), but then I had two service-starting services running my system. Upstart had some of the features, but was still finicky (and the versions I had available didn't consistently have good service supervision support).

systemd just fix that.

Also, with systemd, for the first time I feel like I'm really using Linux, not just a random *Nix that has adequate drivers.

IIRC, the gpg-agent is sadly not that capable or intelligent. In theory, it should be usable for this.

In practice, I believe the agent actually just retrieves the passphrase and hands it to the requesting program, which is then responsible for actually working with the private key. So it doesn't keep your keys safely out of the hands of 'normal' programs, even though it seems like it should. Although it is somewhat confusing, and gpg-agent seems to mediate access to smartcards.

Protocol docs here: https://www.gnupg.org/documentation/manuals/gnupg/Agent-Prot...

The ssh-agent, on the other hand, does keep the key material out of the ssh client executable.

> The research project was partly funded by NSF grants, so does that mean the public have the right to see all work related to the project?

For better or worse, no. NSF funding brings requirements for data sharing, but does not automatically trigger code availability.

If it accidentally worked due to bugs/spec violations in the old OS, but is nonconformant in broken ways?

FF uses fallback. Chrome and other WebKit-based browsers, however, do not.

I don't have good examples of what can or cannot be done.

But I find pf much easier to understand. I can write pf rules myself and understand, clearly, what my firewall is doing. I haven't found iptables near as approachable, and depend on firewall configuration tools to generate the rules and chains for me.

Because it improves the quality of delivery of their service (e.g. video-on-demand). The Internet user won't notice the improvement - their Internet speed would remain the same, by metering - but the actual pipe improves so they can deliver more/better video (and reap the profits from it).

FLOSS Weekly had one of the lead OwnCloud devs on recently. Of course, he was asked ‘why PHP’. Answer: to make it possible for as many people to deploy it as possible, on commodity shared hosting (or anything better they might have).

There's basically nothing that can achieve that level of deployability besides PHP.

Hearing that reasoning helped me with some of the concerns I had about its implementation language. It sounds like they know what they are doing, and are very careful (including careful code review), they just want the software to be as widely usable as possible.

GNU License ≠ GNU Project. Yes, (almost) all GNU software (as in projects of the GNU Project) are released under the GPL. So is a lot of other software.

GNU Foo is, branding-wise, just like Microsoft Word, Google Drive, or Apple Macintosh.

Anyone using RHEL6's built-in virtualization technology is using KVM, it's just all wrapped up in libvirt stuff. Those tools were in early development 7 years ago.

KVM is used, a lot: it is the backbone of Red Hat's virtualization in RHEL6. Also, if you create a new VM using Gnome Boxes, you will have a KVM VM unless you go out of your way.

How can they have legal standing for such a claim, unless one of the authors had privileged access to Wolfram Research knowledge to misappropriate a trade secret? Seems to me that the principle of trade secrets should have a clear defense for independent rediscovery, although law often fails to reflect common sense.

Go does have a much better concurrency story, OCaml's is rather weak (as others have observed).

For the work I do (data analysis and scientific research, particularly on recommender systems, with system-building to support that), if I need concurrency, it's suitable to run the program on the JVM. So I would use Scala in that case, and OCaml would be fine for the other systems-y stuff.

I personally have taken to writing such code in Haskell these days, but that's largely to practice my FP skills in a manner that's easier to transfer back to Scala.

It depends on what you are working on. OCaml lets you interact more closely with Unix and with C libraries, if you need that. It also has a lot faster startup time and lower memory overhead, making it somewhat more suitable for writing Unix-style programs that need to run quickly with low overhead.

I also moved from OCaml to Scala for my primary programming, and have really enjoyed it. The functional goodness on top of JVM is a major win for the kinds of things that I primarily work on these days.

When I was working with OCaml, the community was going through a lot of work on figuring out what the ecosystem should look like. This involved at least two competing standard library extensions or replacements (Batteries and Jane St. Core), growing pains in packaging & deployment, etc. The language was (and still is) nice, but I could not, at the time, invest the time into dealing with the ecosystem. Things seem to have improved a lot since then, particularly with things like OPAN emerging, but Scala is still a better fit for the work I do, and Haskell has been serving me well for command-line kinds of things. But OCaml is a fine, practical language for a lot of things.

Not everyone has notes. When I lecture, I do so from notes, but I usually do other presentations without them. I'll likely have created an outline, but it has less information than the slides.

Yep: http://data.linkedin.com/publications

That's on your file system.

The HTTP protocol specifies that, if the server says a document is 'text/plain', the client must not attempt to second-guess it based on content.

IE second-guesses it based on content, so you cannot serve up something that looks like HTML as text/plain to get it to display.

Substantially worse, IMO.

That said, it'd be better to actually save content types in extended attributes or something. And make all applications magically save and respect these attributes.

And break Cygwin/MSYS/<*nix compat layer> that provides install(1).

OCaml also internally uses an intermediate code representation called C-- (or Cmm). I do not know if the two have any relationship.

Python does not compile to C (well, there might be such a compiler, but it is not the standard mode of operation).

In CPython, Python compiles to bytecode, which is then interpreted by the Python interpreter (which itself is written in C).

My Ph.D adviser (who was also a close colleague, mentor, and friend, very much not Ph.D's Prof. Smith) died this summer. One of the most acute grief triggers early on was seeing him in my chat roster (and shared Google Docs, calendar events, etc.).

If you want similar backup capabilities to your own server, check out obnam or bup. Both do de-duplicated remote backups with differing tradeoffs and capabilities in security, efficiency, etc.

The FSF is happy to consider projects under permissive free licenses (MIT, BSD, APL, MPL) to be free software. Perhaps not ideally-licensed software, but they have no problem calling them free software.

I wish this perspective were more widespread.

Systemd takes the cool stuff that's been getting into Linux under the hood and makes actually usable to everyday users and administrators.

And it's far easier to write a systemd unit than a startup script for any other init system (except DJB's daemontools, perhaps).

The problem I have with this approach - keep everything compatible and portable - is that it holds back development and puts the effort in other parts of the stack to waste.

What is the point of awesome ‘new’ kernel features like cgroups if nothing in userspace really uses them? With systemd, I feel like my computer is actually taking advantage of being a modern Linux system, not just a warmed-over historical UNIX.

With Gnome using systemd, it can take advantage of those capabilities as as well.

If they do not depend on systemd, they have three options:

1. Don't have features that require its capabilities.

2. Have those features conditionally depending on whether systemd is present. This has at least 2 problems: inconsistent experience / feature set and maintenance of less-tested alternate code paths.

3. Implement fallbacks for systemd capabilities. This has more maintenance problems than (2), in addition to the redundant effort re-implementing (subsets of) features systemd provides.

I prefer to see the Gnome leverage systemd and build an excellent platform. With scarce resources, (2) and (3) are a significant drag on the project. 'Choice' is not only hard, it requires time/money, and that time/money comes at the expense of other things that would benefit from it.

I'm not a fan of the lab books — they don't lie flat enough for me — but I do like my gridded notebook (high-quality company swag notebook courtesy of ipHouse). When that notebook fills, I'm not sure what I'll use to replace it.

I also really like Zebra F-301 (and compatible) pens. Inexpensive enough to justify easily buying (and buying again when I lose them), good enough to be worth buying refills for. I keep at least a black one, and often blue, everywhere I am likely to need a pen (home desk, work desk, bag). And the F-301 Compact is often in my pocket when I don't have my bag with me.