j-kidd

But I can have an OS with wonderful package management, developer tools, endless configurability AND a desktop Aaron Seigo and friends created.

As someone who uses the shell all day, I found that there is no alternative for portage and Konsole.

And since most things are web-based now, a vanilla KDE setup + Icon-Only Task Manager is awesome enough for me.

Personally, I think ticket description is more important than code, so I always create a ticket first. Unfortunately, github's issue tracker doesn't allow attachment, and thus it inadvertently promotes this "pull requests from out of nowhere" behavior.

Call me old fashioned, but I still like ticket + attached patches way more than anything else. Recently, I stumbled upon a Google Code project with several defect issues. One guy commented on each of the issue with a link to his github fork which he has applied the fixes. I clicked the link, and found that the fork has been deleted. What a waste.

That sounds like a weird example. I have never associated the gaming demographics with Christmas shopping.

Thanks for sharing. The first article is really interesting. The author worked 3 months as an intern at Google, and his much under-appreciated works saved Steve Yegge's Grok team that has been struggling for years.

EDIT: Found another gem from the same author: http://yinwang0.wordpress.com/2012/04/09/reinvent-y/

> Today I found that I forgot how to derive the defintion of the Y combinator. I learned it several years ago from an online article, but now the search term “Y combinator” gives me all the news about startups (sigh).

> You can certainly use it the same way you'd use Subversion and it's not any harder - it'll just behave as a version control system that can buffer commits offline with two "levels" of commit - local and remote.

That's hg. With git, you got the index / staging area, which is unique to git (no idea if bitkeeper has it). In other tools such as svn or hg, there is no need for flags such as "commit -a", "diff --cached", and "add -N".

> If you want to use the more complicated stuff, then there is no way to avoid learning the more complicated ideas.

And this is what we hate about git. Version control shouldn't be complicated for 99.9% of projects. I have used svn for 3 years and hg for 2, they get the job done just fine without cryptic commands and flags.

That's exactly the problem, i.e. those people who endlessly promoting git so that they can be seen as elite developer. Their favorite past time is to share their "get it" stories with the rest of the world.

Not unlike the "Are You There God? It's Me, Jesus" episode of South Park.

Check out this long thread on WHT, started 2 months ago:

http://www.webhostingtalk.com/showthread.php?t=1151090

From my limited testing, a 1 Node instance from GridVirt at $30/month can compile gcc-4.6.3 within 15 minutes (not exactly an IO-intensive example...)

It says 3Gbps here:

http://www.solid-run.com/mw/index.php/CuBox_hardware_specifi...

I am just about to place an order. They finally have stocks, though the current price is 10 USD more compared to the pre-order price.

Yea, I am not sure if "quad-core Raspberry Pi" is that much of a selling point. CuBox is much more interesting with:

- gigabit ethernet

- e-sata port (with port multiplier)

- infrared receiver

- out of the box, already comes with a box

- comprehensive wiki for a development platform

By the way, a 150 Mbps wifi dongle is sold for about 5 USD here (I too was surprised by how cheap the wifi module is, and went to check the price list).

Pip is great for many many use cases, but I think it kind of get overhyped as a replacement for easy_install. People just get upset when they encounter situation where it doesn't live up to the hype.

Self hosted PyPI (with eggbasket or even a static dir listing), combined with easy_install, is an old and unsexy solution that just works. Instead of saying we are limited to easy_install on Windows, I say we are embraced by setuptools on all platforms.

Make donation here to add unofficial support for Asus RT-N66U in OpenWrt:

https://forum.openwrt.org/viewtopic.php?id=37069

By the way, I think most TP-Link products are using an Atheros chipset. Very affordable and really well supported by OpenWrt.

I think both TP-Link and OpenWrt are very much under-appreciated. Glad to see their names appear here.

By the way, anyone who is using Gentoo should really try to compile your own OpenWrt images. It is a fun exercise (if using Gentoo is fun for you ;)).

Good points. The changing keyboard layout can definitely be a source of frustration. My current Edge 11 has Insert/Delete/Home/End at the upper right corner. In the latest refresh, Lenovo changed the order to be Home/End/Insert/Delete, which in my opinion is less programming friendly.

Anyway, I am getting a E530 with full keypads so hopefully this won't be a problem.

What problem do you have with the chiclet keyboard on Thinkpad? For me, it is awesome, and ever since I started using one 18 months ago, my laptop buying criteria became "Is it a Thinkpad with chiclet keyboard?"

I am glad Lenovo switched all lines to chiclet keyboard in the latest refresh. I think it is a bold but calculated move.

If you don't need to run cmd.exe, then this is likely not for you.

On Windows, I deploy native 64-bit Python, and the application has quite a few command line pyramid scripts, which works perfectly fine with grep, cut, sed, sort, etc from gnuwin32. Don't see the need for cygwin.

I thought the same. Then I found that Gow is shipping way older versions for many binaries compared to GNU-Win32, and its patch.exe causes UAC prompt for non-administrators.

GNU-Win32 is solid, integrates natively, and is good enough for deployment purpose.

Or unbound's python scripting. Or if GeoScaling slightly improves its excellent smart subdomain service, 2 lines of php script.

Or you can add rebind-domain-ok=xip.io to dnsmasq.conf. Not that I would do that myself, as I still don't see what value it provides.

Perhaps the commands renaming was done to make TortoiseGit more consistent with TortoiseHg and TortoiseBzr?

Yeah, this is another big one. I first came across the temporal project [1] in year 2008. Glad to see that it finally makes it to release.

[1] http://pgfoundry.org/projects/temporal/

The title of the linked article is actually "PostgreSQL 9.2 beta improves scalability, adds JSON". Not sure why it get truncated.

I, for one, am not excited by the JSON addition at all. On the other hand, index-only scanning, scalability improvement, and reduced power consumption are all very big deal.

> We're sort of destined to hate ORM, because the people who love databases aren't going to love ORM no matter what, and people who hate databases will resent how much effort they require to use properly.

Speak for yourself. I love databases (note the plural form) and love ORM. ORM is a godsend for developing application that has to work against different databases (postgresql, mssql, db2, etc).

Well, SQLAlchemy is designed just for that. In the words of the author:

> Like "power steering" for SQL. Doesn't teach you how to drive!

The problem with SQL is that everyone thinks they know SQL.

So, on one hand, you have a group of people who think they know SQL well enough and dismiss it as inadequate. These are people who build schema without foreign key and run queries without JOIN because they "know better".

On the other hand, you have a group of people who think they know SQL well enough and fall back to it whenever possible. They go on to create views on top of views on top of views, create temp tables to hold intermediate values that get discarded right away, format application output with string concatenation in SELECT, add DISTINCT to SELECT whenever in doubt, etc etc.

We have an interview question (for a senior position) to test if the applicant grasps the concept of "EXISTS/IN (<subquery>)", and thus the concept of set-based SQL. Nobody has got it right yet, though they all can write a ton of SQL.

That is exactly my point - you have to build multiple packages for the same app, even for the same version (app1_venv_a-1.0, app1_venv_b-1.0), if there is a need to have more than one instances of it running on the same machine.

Until emerge/apt-get/yum/etc add support for virtualenv, I will stick with .egg packages and be python-native rather than system-native.

Of course, it has always been possible to have multiple versions installed with native packages. Gentoo supports that since day 1. What I was talking about though (and I didn't make it clear), is having the same version installed multiple times in different locations (i.e. separate virtualenv).

I think native packages make things too rigid. A private PyPI server hits the sweet spot for us. The steps to deploy an update is as simple as:

1. activate virtualenv

2. run `easy_install -U app`

and no root permission is required. It also has the added benefit to allow having multiple copies of the same package in the same machine [1], which can't be done with native package.

[1] In one deployment, we have staging instance and production instance in the same machine...

> For example if the code is buggy and shared, odds might be higher that the bugs will never be found because nobody will bother trying to write the code again.

Your reasoning is a bit odd. It's a good thing that nobody will bother trying to write the code again. The world has enough people who can write code. We need more people who can read and dissect code, refactor them, and add tests where applicable.