start new:
tmux
start new with session name:
tmux new -s myname
""" | |
Benchmark sklearn's SGDClassifier on RCV1-ccat dataset. | |
So generate the input files see http://leon.bottou.org/projects/sgd . | |
Results | |
------- | |
ACC: 0.9479 | |
AUC: 0.9476 |
-server | |
-Xms2048m | |
-Xmx2048m | |
-XX:NewSize=512m | |
-XX:MaxNewSize=512m | |
-XX:PermSize=512m | |
-XX:MaxPermSize=512m | |
-XX:+UseParNewGC | |
-XX:ParallelGCThreads=4 | |
-XX:MaxTenuringThreshold=1 |
# Generate (x, y) data with a sparse set of active predictors | |
# prob controls the frequency of predictors having zero effect | |
function simulate_date(n::Integer, p::Integer, prob::Real) | |
x = randn(n, p) | |
beta = randn(p) | |
for j in 1:p | |
if rand() < prob | |
beta[j] = 0.0 | |
end | |
end |
Update (2019-05-06): The Broadcom wireless card in the MacBook Pro works and can be crammed into the Air.
Update (2015-12-04): This document used to be very lengthy as there were many manual steps required to get OpenBSD and Mac OS X working together through Boot Camp Assistant (BCA), which created a hybrid MBR and enabled a legacy BIOS emulation mode which older versions of Windows (and OpenBSD) required. Newer Macbooks stopped supporting older versions of Windows through BCA and now only support Windows 10 since it uses GPT and UEFI. However, now that newer versions of OpenBSD support GPT and UEFI, Boot Camp Assistant is no longer needed at all to boot OpenBSD.
OpenBSD works pretty well on at least the Mid-2011 Macbook Air (A1370, SandyBridge) and Mid-2013 Macbook Air (Haswell). The new KMS code in 5.4 brings up the MBA's eDP display in 1366x768 with backlight
Ideas are cheap. Make a prototype, sketch a CLI session, draw a wireframe. Discuss around concrete examples, not hand-waving abstractions. Don't say you did something, provide a URL that proves it.
Nothing is real until it's being used by a real user. This doesn't mean you make a prototype in the morning and blog about it in the evening. It means you find one person you believe your product will help and try to get them to use it.
Here's where I understand the state of the art to be:
RDBMS-based job queues have been criticized recently for being unable to handle heavy loads. And they deserve it, to some extent, because the queries used to safely lock a job have been pretty hairy. SELECT FOR UPDATE followed by an UPDATE works fine at first, but then you add more workers, and each is trying to SELECT FOR UPDATE the same row (and maybe throwing NOWAIT in there, then catching the errors and retrying), and things slow down.
On top of that, they have to actually update the row to mark it as locked, so the rest of your workers are sitting there waiting while one of them propagates its lock to disk (and the disks of however many servers you're replicating to). QueueClassic got some mileage out of the novel idea of randomly picking a row near the front of the queue to lock, but I can't still seem to get more than an an extra few hundred jobs per second out of it under heavy load.
So, many developers have started going straight t
There are three easy to make mistakes in go. I present them here in the way they are often found in the wild, not in the way that is easiest to understand.
All three of these mistakes have been made in Kubernetes code, getting past code review at least once each that I know of.
What do these lines do? Make predictions and then scroll down.
func print(pi *int) { fmt.Println(*pi) }
This project has moved to https://github.com/jonhoo/drwmutex so it can be imported into Go applications.