rwg

I don't agree that file-based disk images are more flexible than LVM's logical volumes — it's ridiculously easy to create, destroy, resize, and snapshot LVs.

Now, about Trim... Trim is only an advisory command. You tell the disk, "I'm not using these LBAs anymore, so feel free to do whatever with them." The disk has the option to completely ignore your Trim command, and even if it does mark those LBAs as unused in whatever LBA->NAND mapping table it uses internally, the disk can also continue returning the old data on reads of those LBAs if it wants to. There are disks that make the guarantee that Trim'd LBAs will always read back zeroes until written again (an ATA feature called Read Zero After Trim), but I'm guessing DigitalOcean isn't using SSDs that support RZAT since that's generally only found on more expensive SSDs, like Intel's DC S3700.

What I'm getting at is that Trim isn't guaranteed to do what you think it does. Unless the disk supports RZAT, the only way you can guarantee that the disk won't return old data in response to a read command is to write zeroes over that block.

If you're a VM provider and can't count on Trim doing what you want it to (reading back zeroes on Trim'd LBAs) because your drives don't support RZAT and you don't want zero out partitions at creation or destruction time, the right thing to do is encrypt every partition with its own randomly generated key at creation, then destroy the key when the partition is destroyed. Users will see random data soup on their shiny new block devices, which isn't as nice as seeing a zeroed out block device but is still nicer than seeing some other user's raw data. (Also note that doing this doesn't stop you from also issuing a Trim for a partition when destroying it so the SSD gains some breathing room.)

I'd argue that there's no demand for TLS-SRP because most of the people who could make use of it don't even know it exists. (Conventional thinking is that the only way to do authentication in TLS is with X.509. TLS-PSK has the same problem.)

But applications can't reasonably support TLS things that the TLS libraries they use don't support. Two of the three elephants in the TLS room, SChannel and NSS, don't support TLS-SRP. The other elephant, OpenSSL, has supported it for less than two years.

There's interest in (and patches for) adding TLS-SRP support to NSS, but they don't seem to want to implement anything that Firefox won't use:

https://bugzilla.mozilla.org/show_bug.cgi?id=356855#c25

(As an aside, I think NSS's position on supporting TLS-SRP highlights the biggest problem with chaining your code to a library produced by another entity for their own use: unless you have the ability to fork and maintain it yourself, your future use of that library is at the mercy of the other entity's interests. Fedora is porting all of their TLS-using packages to Mozilla's NSS, a project that exists for other Mozilla products' benefit. node.js is joined at the head to Google's V8, a JavaScript engine that exists for Chrome's benefit. My crystal ball shows both situations ending very badly when these projects' needs and directions get far enough out of alignment.)

It looks like they've fixed the first problem by switching to gzipped WARC files, but I can't find any information about whether or not they're still truncating documents in the archive. I guess I'll have to give it another look and see...

As an example of the latter, I have a Monoprice-rebadged Tenda W301A ceiling-/wall-mount AP on my desk. It only has 2 MB of flash and 16 MB of RAM. It has a TTL serial port, but the lines are broken out to surface pads that aren't even grouped together on the PCB. (They're not labelled on the silkscreen, either.) The version of u-boot it ships with is stripped down to nothing, probably because of the limited flash space available. For ≤$5 more on the BOM, these problems could be fixed, and the device would be considerably more useful.

I think it's a case of "everyone else is doing it, so we should, too!" Or maybe I'm completely underestimating the "oooh, shiny!" effect on a website's average visit duration.

---

1. https://twitter.com/areuugee/status/380384096762867712/photo...

• TCP-in-TCP (or ${ANY_RELIABLE_STREAM}-in-${ANY_RELIABLE_STREAM}) performs very poorly in the face of packet loss.

• SSH itself becomes a bottleneck on networks with a large bandwidth-delay product because of statically sized buffers in the client and server. (Though there's been some work done in OpenSSH to mitigate that.)

• "Real" VPN software generally has niceties like MSS mangling TCP connections inside the tunnel to help prevent fragmentation of the encapsulated packets due to VPN overhead.

SSH is great when you need a quick and dirty tunnel (I use it in SOCKS mode a fair bit), but it's not something I'd want to use for long-lived tunnels that will see a lot of data.

But the Visual Workstation line's failure was merely one gut punch in a succession of gut punches that destroyed SGI. SGI had two core competencies: graphics workstations and HPC. The availability of cheap (comparatively) multi-processor x86 workstations running ports of formerly IRIX-only software killed their workstation lines, and the combination of Itanium being late, Itanium trailing way behind x86 in $/FLOPS and watts/FLOP, and x86 clusters with fast Myrinet (later 10GigE and Infiniband) interconnects becoming in vogue killed most (not all, but enough) of SGI's HPC market share.

(I type this all with a bit of sadness: part of my first job out of college was running and porting software to a 20 CPU, 20 GB RAM SGI Power Challenge 10000, and I still have a soft spot for exotic big iron.)

Excel also has a tendency to get crashy when you have a very complex cell dependency tree...

One of the biggest things to wrap your head around is that cells in Excel are write-once, read many. This forces you to unroll all of your loops, and you generally end up with a giant state machine, with each state occupying a row and depending on the state of the previous row.

However, I think it's unfair to say clock speed is an unfortunate marketing gimmick "anymore" when it was a gimmick all the way back in 2002 when Intel released the 3.06 GHz "Northwood" Pentium 4 that the OP's linked article references. In fact, it was a gimmick that caused one of the biggest strategy/roadmap blunders Intel ever made.

Intel designed NetBurst (the architecture that the P4 was based on) to do one thing really well: allow Intel to ramp up clock speeds quickly. The architectural choices they made to enable this severely hobbled the P4's performance, especially the 20 (later 31!) stage pipeline that made the penalty for branch mispredictions pretty awful.

Intel eventually released P4s that clocked as high as 3.8 GHz and had an unheard of (in the x86 space) 115 watt TDP, but when the Athlon 64 was released, AMD could smoke Intel's fastest P4s using slower clocked CPUs with lower TDPs. Instead of focusing on raw clock speed, AMD focused on architectural improvements like x86-64, HyperTransport, and an integrated memory controller. (Intel CPUs wouldn't see QPI or an integrated memory controller until Nehalem, released five years after the first Athlon 64.)

As you say, the tables are now turned — clock for clock, the IPC of AMD's Piledriver core is behind that of even Intel's (two generations old) Sandy Bridge core, and all AMD seems to be able to do is add more cores and crank up the clock speed. Unfortunately for AMD, adding more cores doesn't help single-threaded performance, and a very nasty side-effect of increasing clock speed is that the processor's TDP increases disproportionately: the 4.7 GHz FX-9590 has a whopping 220 watt TDP, while the 4.0 GHz FX-8350's TDP is 125 watts.

As a job-seeker, getting strung along or getting the silent treatment after interviews is the worst thing in the world, especially if the candidate really wanted the job and/or has other opportunities on the table.

    /* the initial numbers generated are "less random" so will be discarded */
    #define RNG_WARMUP_COUNT 0x40000

What's not to like about it?! The potential for multiple processes to share PRNG state after fork()s (unless the processes explicitly reseed)? The tri-state return value from the RAND_bytes() function (success, failure, more failure)?

I'm also guessing it's based on one of Intel's upcoming "Silvermont" Atom CPUs. That makes me very unlikely to support this project since I'd imagine the market's going to be flooded with similar products well before this project's estimated ship date.

Gruff old professor explained that using H J K L was the True and Proper Way and the arrow keys were a work of the Devil, so to make sure we were not tempted by the Dark Lord of cursor motion, he had the department's system administrator recompile vi on the department's (pathetically overworked) Sun to remove support for the arrow keys.

(As an aside, if you've never tried working interactively on a Unix box whose load is higher than its CPU speed in MHz, you've really missed out.)

Rather than get used to using H J K L, I spent that evening waiting for a new vi executable to build in my home directory.

Laziness will find a way.

A friend told a story about a recent job interview for a devops position. He'd already had phone interviews and a breakfast chat with some engineers from a company with offices in his city, and all that was left was meeting the bigwigs at their office.

As the interview started, one of the executives asked, "So what programming languages do you use most often?" My friend replied, "Well, it depends on the job. PHP, Perl, Python, shell, ..." "Oh," the executive interrupted, "so you're not a programmer, you're a scripter!"

I understand and appreciate the sentiment that marking up text isn't programming, but it reminds me of the sort of mindset that says you're not a real programmer unless you're banging machine code into memory using the front panel of a MITS Altair 8800.

                USB to ATA/ATAPI Bridge:

                  Product ID: 0x2338
                  Vendor ID: 0x152d  (JMicron Technology Corp.)
                  Version:  1.00
                  Serial Number: 152D203380B6
                  Speed: Up to 480 Mb/sec
                  Manufacturer: JMicron
                  Location ID: 0x24112000 / 6
                  Current Available (mA): 500
                  Current Required (mA): 2

It does: "When any scalar value is converted to _Bool, the result is 0 if the value compares equal to 0; otherwise, the result is 1." (from §6.3.1.2 of the N1256 draft)

Compilers will happily compare/set pointers to 0 since that's the null pointer constant (§6.5.9, §6.3.2.3), so there's no warning:

    % cat foo.c
    #include <stdio.h>
    int main() { _Bool b = "blah"; printf("%d\n", b); return 0; }
    
    % gcc -std=c99 -W -Wall -Wextra -o foo foo.c
    
    % ./foo
    1

http://www.popehat.com/2013/08/29/this-is-no-surprise-to-you...

    kftaba ‏@kftaba 23 Aug
    How living out of my Tesla made me more productive #FalseMedium

"man nfs" and "man mount.nfs" and search for "soft", "intr", "tcp", and "timeo". It sounds like the solution to your problem is some combination of those options.

http://i.imgur.com/TEUoGrT.jpg

http://trac.nginx.org/nginx/browser/nginx/src/http/ngx_http_...

OpenSSL on most Unix-alike platforms has been seeding its default CSPRNG (which uses SHA-1 internally unless you've built OpenSSL without SHA-1 support) from /dev/urandom for over a decade. I don't understand why has everyone suddenly started framing /dev/urandom as a gigantic crypto bogeyman to be avoided at all costs. It just isn't so.