kelleyk

I made this mistake. I love where I've wound up, but I would have gotten there much more quickly and with a lot less heartache if I'd worked as part of an existing company before starting my own.

It is! If you also need service, Google Fi has had a promotion for a while that gives you the $500 purchase price back over 24 monthly bills.

In fact, they also have a promotion right now where you can get $800 back on either the Pixel 9 or 9 Pro, spread over 24 months; that makes the 9 free and the 9 Pro only $200.

There are three "example programs" available on your website, but none of them are very interesting.

I'd love to see better examples of subtle problems that your tool can detect: the kind of thing where an engineer says "oof, yes, that's obvious now that you've pointed it out" but wouldn't have noticed it right away on their own.

You can absolutely ignore it, even without switching inputs; it appears above the menu/input bar at the bottom and isn't modal.

However, it reappears every time the TV is turned on. At some point, a houseguest (assuming those are a thing at some point in the future) is going to hit "okay", or I'm going to do so accidentally while fumbling with the remote, and that isn't the same thing as actual/deliberate consent from me, the owner of the device.

_Can_ you reject Samsung's EULA? My Q90T prompts me to accept it every time it's turned on, but the only option appears to be to accept it. I can't find a "no/reject" option.

I do what you suggest in step (3), and never connect it the TV to a network, but it's still concerning.

Also, if you need to interact with a Supermicro BMC that doesn't support the HTML5 console (for example, because it's running older firmware), I reverse-engineered the proprietary "iKVM" protocol (along with a lot of other parts of the BMC) and implemented support for it on a branch of noVNC, which you can find here: https://github.com/kelleyk/noVNC

I haven't seen anyone mention that Docker Hub's automatic build integration requires either "Owner"-level permissions on your organization or "Admin"-level permissions on the individual repository. Based on the GitHub-side audit log, Docker Hub seems to be using this access to add deploy keys to your repository, but this isn't mentioned in the documentation (which is why we had to go spelunking in the audit log), and if you try to take a least-privilege approach and grant only the read-only access that Docker Hub should require, your GitHub repository will simply not appear in the list of available repositories when you try to configure an automatic build.

Lots of people may have exposed credentials to Docker Hub that can do much more than disclose proprietary source code.

Out of curiosity, what do you do that you get to do that? Sounds fascinating---I've had lots of fun with dtrace (and, more recently, bcc).

There may be nice things to say about Veritas, but they charge an extra $99 for VCF files, and the actual raw data (FASTQ/BAM) is not available at any price (to you; Veritas has it). This is after you've paid $1,000 for sequencing.

That's not because it's slower; that's because it's the low-end (non-programmable) member of its family. It was designed by a company called Fulcrum, which produced the FocalPoint FM2000/FM3000/FM4000 (1/10G) and FM5000/FM6000 (10G/40G) switching ASICs before being acquired by Intel.

I think that a comparison to the FM4000, which is the programmable series of parts in the "Monaco" family, would be more fair. Here's their datasheet: https://www.intel.com/content/dam/www/public/us/en/documents...

The FocalPoint ASICs were, as far as I know, some of the first to support (a demo-quality implementation of) OpenFlow in hardware. When Intel bought them, they released the datasheets, which is neat.

As a real-world example, these ASICs were used in Arista's 7100 series (c. 2008) switches. They published a two-part "Technical Evaluation Guide" for those switches which are, among other things, an interesting glance at how switches are constructed out of ASICs. Part 1 (https://local.com.ua/forum/index.php?app=core&module=attach&...) shows the topology of each switch (starting on page 13).

The 7124 is a single 24-port FM4224 with all 24 ports connected to front-panel ports. The 7148S has three FM4224 ASICs; each is connected to 16 front-panel ports and uses 4 ports (40 Gb/s) to connect to each of the other two ASICs in a ring. Intuitively, this means that it's possible that those inter-ASIC connections could cause bottlenecks (if e.g. all 16 ports connected to the first ASIC try to send 160 Gbit/s of traffic to the 16 connected to the second ASIC, they'll saturate the 40 Gbit/s of connectivity between the ASICs). Therefore, Arista also offered the 7148SX, which is non-blocking but needs six (!) FM4224s to make it happen!

A nice overview; thanks for sharing it!

I don't think that your claim that GRO is "a software implementation of a hardware optimization that is known as Large Receive Offloading (LRO)" is correct, though. GRO effectively replaces LRO [1]; it has fewer limitations (it works with non-TCP traffic and with bridging [2], for example). Drivers need to support it, but they are free to take advantage of hardware offloading/acceleration, and many do (including e.g. the ixgbe driver [3]).

----

[1] In terms of function, and in the sense that LRO could be removed if the drivers that were using LRO were updated to use GRO instead.

[2] Relevant bug: https://bugzilla.redhat.com/show_bug.cgi?id=772317

[3] Which actually supports both LRO and GRO; if I recall, in older versions, bad things(tm) would sometimes happen if you had both enabled at the same time (whereas now the LRO setting is ignored if GRO is enabled).

This is actually not the whole story. WinZip archives can be encrypted like you describe, but they can also be created with both the data and the list of contents encrypted.

Have you heard of Device Tree? Linux supports it on the x86, ARM, and PPC architectures, among others.

(http://events.linuxfoundation.org/sites/events/files/slides/..., http://www.devicetree.org/Main_Page, https://en.wikipedia.org/wiki/Device_tree, http://elinux.org/Device_Tree)

Linode's is the same. I agree that it's annoying and that the terminology is slightly deceptive.

Any of these "datacenter LANs", though, tend to be fast and free (in terms of bandwidth). We just use a VPN overlay and call it a day.

I haven't had a chance to play with it, but I ran across this project the other day: https://github.com/cloudius-systems/osv

"OSv was designed from the ground up to execute a single application on top of a hypervisor... OSv... runs unmodified Linux applications (most of Linux's ABI is supported) and in particular can run an unmodified JVM, and applications built on top of one."

It seemed like an aside, but the issue of being at the mercy of the people who provide platforms and other foundational technology really resonates with me.

("Building on top of a platform is a foundational risk, and if your platform decided one day that it doesn’t like what you are doing, or likes what you are doing so much they want to compete with you, it’s Very Bad. Your platform partner can easily damage your quality of service, or simply shut you down. If that happens, your business is dead.")

Have I missed an explanation from Dalton or the App.net crew about how what they're envisioning will be different? What protects a developer from being at their mercy for uptime, timely bugfixes, continued development, and so on?

Actually, on a more general level... what can platform/tech providers do to provide those reassurances? I can't seem to think of anyone who's done a really stellar job of it.

I'd be curious to hear more about what they're actually doing (technically speaking). Is this a wrapper around kd-trees, R-trees, and their friends and relatives? Is it something fancier?

I'd love to chat, but you don't list a contact email and don't seem to be particularly Googleable. Shame!

That's a bug, not a feature. I leave my phone on vibrate all the time, and when I had an iPhone, the hardware switch would cause it to constantly go back to ringing as I took it in and out of my pocket.

I've been using the wonderful cli53 (available on GitHub here: https://github.com/barnybug/cli53).

All I have to type is "cli53 import example.com --file example.bind --replace --wait" and it'll replace all of the records for example.com with what's in the BIND file, and the --wait makes it poll Amazon until the "pending changes" go through.

I spent about a year working at a non-quant hedge fund out of NYC, and I saw people in similar-sounding situations making $100-125k base, plus another 20-50% in year-end comp ("bonuses"). Recruitment bonuses (or "relocation incentives," what have you) vary widely, too, but seemed to be usually in the lowish-five-figures range.

Of course, I don't know anything about your particular situation; maybe the firm you're talking to has specific interest in you that will take them higher!

Also, like some others have mentioned, your year-end compensation ("bonus") is a big chunk of your take-home---but hard to anticipate ahead of time. Even within a team there can be huge variance (depending on your individual awesome) so the "mean" or whatever figure they're willing to give you doesn't really help.

There are a number of points I'd like to disagree with, but to start:

- $150,000 is much less than a top-flight engineer like the one you're describing might make; it's not out of the realm of possibility for what an engineer with a good pedigree might make his first year out of school, if he went to work for a big company.

- The engineer went to school for four/five/six years and then went to work. The doctor who earns $300-400k went through a four-year university degree, four years of medical school, and a residency or fellowship before he started earning money. Some specialists, like neurosurgeons, take at least 11 years after getting their undergraduate degree before they really "get their wings." Not only are their then-substantial salaries offset by the huge delay in getting those salaries (residents make, what, $35k?) but they also have to pay for things like malpractice insurance, which can be in the six-figure range.

I'd suggest 2x24", which you can do for ~$180/each straight off of Newegg or ~$140-150 if you wait for a sale.

I recently had pretty much the same debate about upgrading my pair of 24" monitors, and wound up moving to 4x24" side-by-side in portrait mode. The extra real estate is totally worth it, but you get the added advantage of having that real estate divided up into screens, where you can maximize/tile windows more easily than on one huge display.

The cost is nice, too; the 4x24" monitors were only ~$700, so even with the extra $120 or so for a pair of decent stands off of Amazon, the damage isn't too bad.

(Just realized you're talking about an extra for a laptop, which makes the situation a bit different. Leaving this up anyhow in the hopes of provoking discussion---I'm curious what people do for multi-monitor setups.)

This is neat, but not new; check out Talking Lights, for example (http://www.talking-lights.com/) --- they were an MIT professor's startup and went out of business a few years ago.

There are also some cool indoor location-finding applications, from what I recall; if each fixture emits a unique ID and you know how they are laid out, you can figure out where in the facility you are fairly easily.

I'd kill for someone to work on a modernized/reimagined emacs. There's so much that's beautiful about The One True Editor, but many things take an obnoxious amount of research/config-poking to make acceptable.

Where do you figure they're getting people to solve 1000 captchas for $2?

I switched from Godaddy to Moniker a little while back---quick, easy to use, and price-competitive. They're outside the US (in Canada), too.

I think that even the "brand-name" CS schools have this problem. Most of our students aren't /really/ going to be practicing computer science (heck, I don't, in industry... not in the purest sense); many of them will be writing software for a company. (Well, or they'll go work in finance, which is a whole different topic.)

While I definitely agree that (as with pretty much any complex skill) the only way to learn is by doing, over and over again, our undergraduates frequently go out into the world having only taken one or two classes that include any sort of nontrivial software development.

Now, these students are largely smart people, and they figure it out---but after two or three years in the workforce. I've heard this from other people, too, who have way more experience with the subject by virtue of having been around longer.

It's sort of an identity crisis thing: are we trying to produce computer scientists, or are we trying to produce software engineers? Neither is a wrong answer; they're just very different goals.

Yes, it will still be taught using Python. Almost all of the undergraduate CS courses are moving from Scheme or Java to Python if they haven't already. (One notable exception is the excellent 6.172, about Making Things Fast(tm), which uses C and Cilk.)

The videos will be recorded this fall semester; Erik will be lecturing again, along with the equally awesome Srini Devadas. In the past, when Erik has recorded his own lectures, I recall that they were posted as soon as they were edited. Every time I've worked with OCW, though, one of their staff members comes in and collects materials at the end of the semester.

I'm not sure exactly what the material differences will be; that's the lecturers' call (way above my pay grade!). If you want more than 6.006 offers, though, check out 6.046, which is the follow-on undergraduate algorithms course.

Since we're doing as much of our planning now as possible, I'm curious: what sorts of things do you wish we'd include? Does anyone have suggestions?

We're actually producing a whole new set of 6.006 video lectures this fall for OCW! (There'll also be some amazing new and reorganized material.)