Interesting talk on Guile 2.2:

Guile 2.2 performance notes (FOSDEM 2016) https://www.youtube.com/watch?v=fU4Tly29Tps

I think the fact this is book is a success shows just how many people are having problems with Ruby on Rail performance.

If they would be willing to rethink their stack, they might have lesser need for such books.

Well luckily these customers have the money for the book because they were able to launch an actual business at least 2 months sooner and can move 5x more quickly than all the competitors still mulling over which lesser productive alternative framework they'd like to use.

I find the voice of the operator at HK airport incredibly soothing.

It almost sounds like it's pre-recorded speech actually. But I agree, very relaxing.

> ECC is nice to have.

Actually it seems ECC is important for ZFS filesystems see:

http://louwrentius.com/please-use-zfs-with-ecc-memory.html

To be clear, it is not ZFS that requires or even mandates ECC. Since ZFS uses data as present in memory and has checks for everything post that, it is prudent to have memory checks at the hardware level.

Thus, if one is using ZFS for data reliability, one ought to use ECC memory as well.

> Actually it seems ECC is important for ZFS filesystems see:

The inflection made by the previous comment tends to lead people to think ECC RAM is needed for ZFS specifically. As the blog post you link to points out it's equally applicable to all filesystems.

It's not required, but it doesn't make sense to use ZFS but not to use ECC memory. That's the point. It's like locking the backdoor but leaving the front door wide open.

"Chelsea Manning acted on her conscience"

Acting on her conscience does not make what she did the right thing to do.

For example, the 2 men behind the boston marathon bombing, did what they did based on their conscience. Did that make what they did right?

> patient, relentless salesman for death.

Tell that fucker to fuck off. You don't have to listen to him. Focus on here and now. The past is gone. Enjoy your life right here right now.

Based on my impression of the hawker trade in Singapore, this is pausible. I am guessing his 17 hours probably consists of the following:

2-3 hours of food preparation in the early morning. 12 hours of manning his stall. The remaining hours for commuting and other work things maybe.

It is likely with the michelin star he can work fewer hours. He can choose to close his stall once he sells all his meat.

It is a hard way of making a living.

The article already states that he has a line of up to 100 people to eat his food. I'm not sure finding customers is his problem.

He will likely be able to raise money now though

You can automate with scripts. No need to use a fancy GUI for this.

And what if I don't want to write scripts because other people have already automated all common database browsing/editing tasks for me? What if I don't want to reinvent the wheel?

With a GUI, you can click 3 times and browse 3 tables. That's just not possible without a GUI.

If GUIs didn't save people (lots of) time, no one would have invented them and the software industry would be moving away from them.

Besides being way faster and more efficient, GUIs do things that CLIs don't:

- linting/error-checking/autocomplete for SQL

- checking query sanity (warn before an unconstrained DELETE for example)

- copy/paste data (within the database and between applications)

- jump from FK cell to the row it references

The list goes on.

Scripted migrations have their advantages too:

- they can be stored in a version control system

- your coworkers can run them at their dev environment

- they can be used for automatic deployment

- you can test it in a dev environment before running at a production server. With GUI tools you have to remember and repeat exact steps you did before

- You can review the script or ask someone to look at it

I think GUI tools might be good for browsing and exploring database but not for making changes.

Softlayer has something like it:

http://www.softlayer.com/gpu%20

Not another dismissive comment about the lack of generics in Go again.

I don't know that it's dismissive so much a factual statement.