cbetz

Yeah, check out the audiobook, it is great and was worth the wait. I have the physical book but it has so many pages and is so heavy that it is hard to hold and read, especially lying down. It probably should be sold in a box set.

I had the same thought and am wondering about the economic reality of doing this.

Does anyone have an idea of the cost increase for using ECC RAM in a mobile device for instance? Are there also power usage concerns to worry about?

AFAIK there are basically zero consumer devices using ECC RAM.

This. I've been trying to put together a small home lab xeon e3 system that can theoretically support nvme+gpu+infiniband. It's tough.

Typically you get something like 3 full length PCIe slotson a xeon e3 board (c236 chipset). BUT they can't all run full speed at 16x (16/16/16). You have to then choose between 16/8/8 and 16/16/0 due to the lack of PCI lanes.

Reverse engineering efforts have only stalled for ARM SoCs using PowerVR GPUs from Imagination Technologies. However for Qualcomm Adreno and Vivante GPUs, the freedreno and etnaviv projects are steadily and quietly moving forward; both have been integrated into mainline Mesa at this time.

For instance, I learned from HN last week that you can run android on i.MX6 with open source GPU drivers. This is a big deal. See: https://www.collabora.com/news-and-blog/blog/2017/04/27/andr...

I find that the only reasonable complaint that can be made about Lua is the from-1 indexing. Like: "I found this really awesome language and it's ONLY wart is that it doesn't index arrays like every other programming language in the world".

Yet, I still admire the Lua creators for making this bold choice. Why should we use from-0 indexing for all eternity? Just because it's always been that way? This is a real question if you have the answer.

I would not be surprised if designing a GPU requires more lawyers than engineers.

I also cannot conceive of many industries where the barriers to entry are higher.

It isn't linked to in the article, but if you're interested in this please do check out luvit by tim caswell (https://luvit.io/). It's a very impressive system.

At a very high level luvit looks like node.js for Lua, with some extra goodies thrown in like being able to bake your apps into single binaries. This is awesome in itself and the article discusses these things.

That said, I think the major innovation over using javascript is that it allows the support for coroutine-based I/O. This means you can get the performance benefits of non-blocking node.js without the headache of callbacks/promises. I think the linked article only touches on coroutines briefly but they are a major piece of Lua's awesomeness that you shouldn't miss.

Though you aren't required to use coroutines, the package management server which hosts packages for luvit is called "lit" and it seems to demonstrate this ability nicely:

"Lit is written in lua and uses the same system platform as the luvit project, but is has a very different I/O style. Instead of using callbacks and event emitters, it uses coroutines so that code can be written with simple blocking I/O, but still maintain the abilities of a non-blocking event loop." (from the README on https://github.com/luvit/lit)

Thank You. Paul Graham says:

'Louis Brandeis said "We may have democracy, or we may have wealth concentrated in the hands of a few, but we can't have both." That sounds plausible. But if I have to choose between ignoring him and ignoring a polynomial curve that has been operating for thousands of years, I'll bet on the curve.'

You mention a very important argument which Mr. Graham seems to have missed, or simply written off: Democracy can be destroyed by wealth inequalities which then create power inequalities. At this point the "polynomial curve" which was made possible by democracy begins to turn down or flatten as we return to corruption, graft, and cronyism.

In other words: We have to baby-sit the growth of this enormously beneficial polynomial curve, for if it gets out of control it will destroy itself (by destroying democracy).

How can you make the claim "It doesn't work". By what metrics?

Both Linus and Bill Gates were extremely successful. Are you claiming they could be more successful with a softer style?

I have another conundrum. Assume both these individuals would have to to do some real amount of work to change their personal style. This translates to time spent not doing the other things they are perhaps excellent at.

Wrapping your argument in nice words all the time is actually really hard. It takes time. Frankly it is not always necessary depending on the relationships between individuals.

Let's say you and I start an open source project and we both find it really hard to say things nicely, but we have X hours a day to contribute and get stuff done. So I propose to you: "Hey, let's get in the habit of saying what we feel. We'll remember and accept that humans aren't always rational and we're going to hurt each others feelings sometimes. We'll remember that we all say and do dumb things all the time, so it's no big deal to call somebody out for it. But we think this will save us time in the long run, since we suck at sugar coating our words and feelings."

What stops us from building a highly successful project of like-minded individuals? What do we lose when somebody comes along and says "hey, you have to be nice now!"? Should we refuse to work with such people?

These are real questions and I don't think they have clear answers.

You're right. The biggest news for operating systems is the fact that the hardware virtualization features on modern processors allow breaking free from the old model.

A modern intel/amd processor lets you virtualize the CPU, MMU, and I/O. Network cards and HBAs can be partitioned into virtual NICs.

Two primary functions of a classic OS are process isolation (i.e. virtual memory) and hardware sharing. But now that these two primary functions have been pushed down into hardware, it has changed the way we think about operating systems considerably.

There isn't much left for a classic OS to do other than provide a common set of APIs for programs to talk through. Yet these days we can statically link even the largest libraries into our exokernels. And hypervisors are capable of using techniques like same-page merging to reduce the memory burden of running many large (exo)kernels at once.

I don't expect the the classic one-OS-running-many-processes model to go away overnight, or possibly ever. But the exokernel model is very compelling for large-scale high performance software services and it will continue to catch on.

economic incentives typically lead firms to look for new sources of revenue. they hope to achieve this extra revenue with minimal cost, ideally by not creating new products or developing new customer relationships. the natural side-effect of this situation for software companies is that they add feature-upon-feature to existing products in an endless quest for growth. at the very end of the road this situation doesn't usually work out well for the product, the user, or the company.

on the other hand there are plenty of services/applications that keep stable interfaces for many years at a time. they do not extend themselves too far beyond solving the problem they originally tried to solve. we can all imagine what craigslist would look like in the hands of short-term profiteers, endlessly tweaking the interface for more ad clicks and "user engagement".

the success of sites like the original google search, craigslist, and HN proves that the "do one thing, keep it simple" model is successful and can often be very profitable in the long term. sadly, it is very easy to forget about such ideals when people are constantly dangling fresh money in your face and/or you have salaries to pay. while page rank might be considered the key element to google's genesis and explosion, we also owe much respect to the people that decided and continually insisted that the UI stay clean and minimal.

Everything works but the webcam.

Unfortunately I had to do some unsavory things like disabling NCQ and write barriers to prevent errors and extreme slowness with disk operations. This was a couple months ago so maybe the issues have since been fixed.

I was using CentOS 7 and whole installation process is described here:

https://docs.google.com/document/d/1GlMtdLLYgoTFs1ZNWsYU4SBf...

Small correction: There is a pure Go implementation of nanomsg (https://github.com/gdamore/mangos).

I donated too. If you're sitting on the side lines: remember that that the Software Freedom Conservancy is a non-profit while VMware is multi-billion dollar corporate entity with very deep pockets and high-priced lawyers.

opposing barrels fired simultaneously might work, though it would be a bit wasteful.

The biggest part of the problem is that companies (and founders) are forbidden from speaking up after licensing deals are made. Perhaps you could post anonymously, but you'd still be violating the NDA in spirit and you'd be punished if discovered.

In other words, if three companies down the block signed millions away to Intellectual Ventures, you would have no idea. Maybe the risk is overblown. Unfortunately we have no idea of knowing.

They try to hammer this point home in the podcast.

It occurred to me there is simple legislation that might chip away at all this shadiness: Pass a law that forbids NDAs in patent licensing deals.

I can't tell if this is an apology or a non-apology. It seems to have elements of both.

Clearly the moral of the story is: "Don't claim that X sucks unless you are are damn sure".

Saying something sucks is fightin' words. Don't expect to people be nice if you are wrong.

this is actually very exciting. I decided to explore the site a little and found this quote:

"most ambitious storage project undertaken since ZFS" (http://www.acunu.com/2011/03/why-is-acunu-in-kernel/)

it looks like they put a key/value store in the kernel and they came up with a new userspace API for it. i can see also see how getting something like this into the mainline kernel is going to be a big uphill battle, but it might actually be a really big win.

within N years you'll be able to pick an android phone out of the trash. I suspect N < 5. That makes projects like this really awesome.

My opinion is that many people hate autotools because they don't understand them. It was designed to handle just about any crazy build scenario you can throw at it -- of course it going to be a little complex.

I started by spending a few hours forcing myself to read the following. It explains how autotools works and (importantly) why.

http://www.freesoftwaremagazine.com/books/autotools_a_guide_...

It is critical to understand what the autotools are actually doing before you just go and copy'n'paste somebody else's configure.ac and/or Makefile.am.

When you are ready to get your feet wet, here is a really good quick summary from the GNOME project:

http://library.gnome.org/users/anjuta-build-tutorial/2.26/cr...

Once you understand what is going on, finding specifics in the GNU manuals (and being able to interpret them) is much easier. Yes, you should understand how m4 works (it's not rocket science).

via the google: http://useconomy.about.com/od/fiscalpolicy/p/Mandatory.htm

"These programs include Food Stamps, Unemployment Compensation, Child Nutrition and Tax Credits, Supplemental Security for the Disabled and Student Loans."

I just saw the link posted by joezydeco (above). It has good links to information on this particular avenue of optimization, particularly: http://elinux.org/Suspend_To_Disk_For_ARM

Would something like uswsusp/tuxonice (software suspend to RAM or disk) be capable of assisting in quick boot times?

Step 1: Build fully functioning embedded system and boot it. Step 2: Suspend it in the state you want it be in on boot Step 3: Hack u-boot to directly load the suspended image

Has anyone done something like this? Is it feasible?

I find the choice of characters and the paragraph descriptions of them a little strange. I get the point that it helps the story to make up a whole life story for each member of the hypothetical development team. What I don't understand is why each team member is portrayed in such a negative light. Are your co-workers that bad?

Please correct me if I am wrong, but shouldn't developers only worry about the issues mentioned in the article on older browsers? (I'm thinking IE6 and earlier).

Introducing a leak via circular references would be considered a bug in most modern JS engines, right?

A related question: Can someone recommend a good plugin/extension for monitoring the size of a page's javascript memory usage over time?

If this is really true, I will consider ebaying my droid, coughing up the $150 cancellation fee and saying goodbye to Verizon forever.

The U.S. badly needs an open (i.e. European-style) cell phone market. Google has (hopefully) realized this and is doing something about it.

In my opinion, he should apologize immediately or else resign. Unfortunately the cat already seems to be out of the bag to some extent. I really hope Sergey and Larry do not have the same disdain for privacy that Mr. Schmidt has exhibited.

I was previously on the fence about trusting Google with all my data and personal information. This one idiotic sentence from the CEO makes the choice to stop using Google services a lot easier for me.