cmccabe

That's not cynicism, it's just realism. The drug companies don't want their product associated with drug abuse, so they add a megadose of something that eventually causes liver failure (acetaminophen). You get a lot of dead addicts, but fewer abuse scandals.

Acetaminophen doesn't actually reduce swelling (although it does reduce fever). Ironically, it's mostly... a mood-altering drug. http://www.theatlantic.com/health/archive/2013/04/whats-tyle...

Let me guess-- you're going to "no true scotsman" all the actual existing open source mobile operating systems.

I've written a lot of code using select and poll, and I don't think it's ever come out "simpler and easier to follow" than code which just used blocking I/O.

Spoiler alert: it's COBOL.

ZFS also has "general lackluster performance" in areas like using memory (it requires tons of it). It's inherent in the design of a copy-on-write filesystem.

According to Ted Dunangst: "ZFS wants a lot of memory. A lot lot lot of memory. So much memory, the kernel address space has trouble wrapping its arms around ZFS. I haven't studied it extensively, but the hack of pushing some of the cache off into higher memory and accessing it through a small window may even work." See http://www.tedunangst.com/flak/post/ZFS-on-OpenBSD

Different filesystems are good for different things. If you want a filesystem that has subvolumes, copy-on-write snapshots, built-in RAID, transactions, space-efficient packing of small files, batch deduplication, checksums on data and metadata, and so forth, you have to pay a price. Just the same way as running Apache with all the bells and whistles is not going to be as fast as ngnix.

I originally had a lot of text here, but let's just leave it at this... something being in Gentoo doesn't mean it's in any way mainstream. I mean that in the nicest possible way (Gentoo can be fun).

Yes, it is terrible advice. Just like this article.

Repeats all the usual myths about Hadoop... that it's just about MapReduce, that it doesn't support indexes (hint: Hive has a CREATE INDEX command, guess what it does?) and then adds some of its own.

After seeing this, plus an article advocating web frontend programming in C, I'm starting to think this place is going downhill fast.

CLOCK_MONOTONIC is affected by NTP on Linux, at least.

UNIX time is not actually seconds since the epoch. It's just something very, very close. There are a few cases where the same time_t value repeats for two seconds in order to insert a leap second.

With regard to Windows, I assume there are equivalents to all these interfaces, but I don't know what they are.

I have a lot of respect for those working on this project, but realistically, if you use Linux, using an out-of-tree filesystem is just asking for pain-- lots of it. I would never use this on a production system. You know how painful out-of-tree video drivers are? Yeah. Imagine that, only now with the potential for data loss and divergent on-disk formats. And if it's your root fs, you can forget about booting if there's a problem.

Sure ZFS has a great reputation, but a lot of that came from how well-integrated it was into Solaris and how much QA was done on it. Neither of those things were ever true (or are going to be true in the future) for the various ZFS-on-Linux projects (yes, there are multiple.)

The comments about btrfs are about 5 years out of date. SuSE has already shipped btrfs in their "stable" 11.1 distribution, and Red Hat is going to do so in RHEL7. Give it a chance.

That's why devices have adjustment knobs and settings that let you adjust the contrast, if you're using it in some unusual situation.

I wrote a blog post about clocks and timers earlier: http://www.club.cc.cmu.edu/~cmccabe/blog_time_and_time_again...

It gets especially interesting when you start thinking about mutexes and condition variables with timeouts.

Yes, absolutely. Anyone can add features to a bloated language. The most beautiful designs know what to leave out and why. C was one of those designs.

If you like the C design aesthetic, you should check out Go. It's like a garbage collected and yes, memory-safe version of C, which substitutes composition for inheritance and goroutines for threads.

Excessive travel is terrible for the environment. You can easily generate many times the amount of carbon dioxide you would emit by driving for a year, simply by taking a long plane flight or two. http://www.nytimes.com/2013/01/27/sunday-review/the-biggest-...

Travel is nice, but not when you do it just to brag about having gone to X countries in Y days. Then it just becomes a status thing, and is, as the author notes, "kind of douchey." The internet, good news sources, and documentaries can broaden your horizons even without leaving the house.

Black on light grey causes less eyestrain than black on white.

http://ergonomics.about.com/od/eyestrain/a/reduce_contrast.h...

What is a "fronted" person? Is that like a brogrammer?

It's not always a nightmare. Sometimes it's quite enjoyable.

I remember going to sleep with a headache at one point and experiencing sleep paralysis. My headache was translated to black and white flashes of light. Or another time when I heard music.

Being unable to move isn't really that big of a deal as long as you are in a comfortable position. Eventually the paranoia and the sense of another presence sets in, but up until that point it can be fun.

If you try to go right back to sleep, you'll probably end up in the same state. Standing up clears sleep paralysis.

Hey guys... let's make a programming language... for non-programmers! Pretty wacky, eh?

It should also look like natural speech.

yep

A lot of the Chrome jailbreaks were done through attacking the embedded Flash player, which wasn't sandboxed at the time.

How well sandboxed is nginx? Answer: not at all. Actually, that's not the answer. ngnix is sandboxed by using selinux, using a chroot jail, using AppArmor, or any one of a number of different ways.

How many years have gone by without a Java or web-based exploit being announced? 0. Maybe you should not throw stones, when your own house is made of glass.

Security and DRM are not two sides of the same coin. There are lots of insecure systems that aren't DRMed. And there are lots of ultra-secure OSes, like OpenBSD, that don't include DRM.

I'm not a tinfoil-hat type of person, but I have a healthy fear of code written by firmware engineers. That's why things like EFI and now this are terrible. They're basically shovelware that you can't get rid of on your PC. Like the uninstallable android apps, but 100x worse.

Go allows you to iterate over a string as a series of code points.

Every modern browser uses sandboxing to avoid having a "trivial software bug allow the author of a web page to upload and run code in your browser process." You simply run the potentially insecure code in a separate, unprivileged process. Apple has a special set of sandbox APIs that make it easy for applications to irrevocably give up privileges such as the ability to write to the file system, etc. It's not as easy on Linux and Windows, but it is possible.

SGX really exists for one reason, and one reason only-- it's another attempt to implement some kind of un-bypassable DRM. Joanna points this out in her writeup. All of the other so-called advantages you can already get simply by running a VM.

Get ready to jailbreak your PC I guess. I can just feel the security oozing from my pores.

Absolutely. If we had reasonable property taxes in CA, we wouldn't have a housing shortage, and middle-class people would be able to live in SF again. But try explaining this to the average voter...

The sender is supposed to close the channel to signify to the receiver that there is no more data to be sent. The receiver is not supposed to close the channel. (You could hack around this by recovering from the panic, but this is bad style.)

https://groups.google.com/forum/#!topic/golang-nuts/RmfHSHE9...

Note that there is no requirement that you close channels-- they aren't like file descriptors. They will be garbage collected after they're no longer needed.

goroutines, on the other hand, will stick around unless you clean them up. goroutines aren't iterators, and you shouldn't use them as iterators. They're more analogous to threads.

Iterator callbacks, generators, or functors feel very un-Go-like. It's trying to force a Python or OCaml idiom on to Go. Basically, what you want is to implement a HasNext and a Next function and write a "for" loop. All you need is this:

  for ; iter.HasNext(); val = iter.Next() {
     // do stuff
  }

There's no reason to look down on the humble for loop. Complexity is a bad thing, usually.

Channels and goroutines are also a very Go-like way to process data. But APIs that return channels assume that the caller wants concurrency, so be sure that that's true.

Use "defer close(ch)". If there is a break or a panic, the channel will be closed.

Oh no! Fashion crisis!

Oh wait-- I just remembered. Wireless chargers exist. Crisis averted.

I live in the bay area, and I wouldn't buy anything from Safeway that wasn't already in a can or a jar when they got it. And sometimes not even that.

In 2012, Consumer reports did a study where only a few "extra virgin olive oils" turned out to actually be extra virgin. Trader Joes has them; Safeway does not. http://www.phoenixhelix.com/2013/03/04/would-the-real-olive-...

Simiarly, would you buy honey from Safeway? It's not actually pure honey. The FDA doesn't enforce any standards as to what can be labelled honey (although they do provide a grade which tells you what color it is) http://www.foodsafetynews.com/2011/11/tests-show-most-store-... Trader Joe's has real honey.

Spinach I buy from TJ's keeps for two weeks, but spinach I buy from Target is already wilted after a few days. I don't know if there's anyone out there measuring produce quality, so I can't give you a link.

Sometimes, it really is about having a better product, not about marketing, positioning, or other bullshit. (And I guess now we're back on topic?)

I disagree with the claim that learning x86 assembly is not useful. I occasionally use inline assembly in my day job. It's very rare, but it does happen. If you're doing C or C++, it helps to know a little bit of x86 assembly when debugging. There are also certain optimizations that you often need inline assembly for, such as using the built-in Intel instruction for CRC32 calculations.

I learned Z80 assembly when writing software for the TI-85. But if I were giving advice to someone interested in learning assembly now, I would suggest learning x86... it's more useful, and just as fun.

I shop at Trader Joe's because there is one very near my house, and the produce is much, much better than anything you'd get at Safeway, Target, Wal*Mart, Giant Eagle, etc. Cutting open a bell pepper to find mold inside is not an experience I want to have again. Nor is buying bagged spinach and realizing that it's already turning brown and soggy.

Let's not over-idealize the situation. Trader Joe's does advertise (they keep sending me paper mail) and they do put things on sale from time to time. Thankfully, they don't have any loyalty card bullshit-- that kind of thing is always a big pain. TJ's also carries a fairly limited selection of items compared to most stores. But it turns out that having a limited selection of items that are not shit is preferable to being a giant warehouse of questionable items.

Well, I work on Hadoop. I don't know what you mean by "modularizing the core." There was an abortive attempt a few years ago to split HDFS, MapReduce, and common off into separate source code repositories. At some point it became clear that this was not going to work (I wasn't contributing to the project at the time, so I don't have more perspective than that).

Right now, we have several Maven subprojects. Maven does seem to enforce dependency ordering-- you cannot depend on HDFS code in common, for example. So it's "modular" in that sense. But you certainly never could run HDFS without the code in hadoop-common.

None of this really has much to do with CLASSPATH. Well, I guess it means that the common jars are shared between potentially many daemons. Dependencies get a lot more complicated than that, but that's just one example.

Really, the bottom line here is that there should be reasonable, sane conventions for where things are installed on the system. This is a lesson that old UNIX people knew well. There are even conventions for how to install multiple different versions of C/C++ shared libraries at the same time, and a tool for finding out what depends on what (ldd). Java's CLASSPATH mechanism itself is just a version of LD_LIBRARY_PATH, which also has a very well-justified bad reputation.

I don't know of anyone who actually uses OSGI. I think it might be one of those technologies that just kind of passed some kind of complexity singularity and imploded on itself, like CORBA. But I have no direct experience with it, so maybe that is unfair.

I like what Golang is doing with build systems and dependency management. They still lack the equivalent of shared libraries, though. Hopefully, when they do implement that feature, they'll learn from the lessons of the past.