jsolson

> I'm not usually one of the slow drivers and I do get annoyed at the slow drivers when I can't pass them but I will still keep my distance and avoid trolling them with horns, lights or otherwise. The road is for everyone and some will be slower than me and some will be faster.

It's certainly their right to drive slowly, but in Washington state it is not their right to delay others:

> Slow-moving vehicle to pull off roadway.

> On a two-lane highway where passing is unsafe because of traffic in the opposite direction or other conditions, a slow moving vehicle, behind which five or more vehicles are formed in a line, shall turn off the roadway wherever sufficient area for a safe turn-out exists, in order to permit the vehicles following to proceed. As used in this section a slow moving vehicle is one which is proceeding at a rate of speed less than the normal flow of traffic at the particular time and place.

https://app.leg.wa.gov/rcw/default.aspx?cite=46.61.427

> I understand there's no way to avoid steep grades in the mountains.

Sure, but your original post assumed he took the more dangerous route. The interstate through the tunnel is no picnic either, and I'd argue it's a tossup whether going through there with all of the cars and other trucks is actually safer than Loveland.

You made an assumption based on experience you don't have that was critical of someone who does this for a living -- in fact, suggesting that the choice made by said person should carry a penalty! That is why you're seeing downvotes.

With you on this one -- I've got all of his major works in first editions -- Seveneves is the only one I actively disliked. It's probably the only one I'll never read again. Beyond being intensely depressing (near future enough that everyone you know and love dies on the page... horribly), the plot felt about as strongly held together as an average episode of network television, and the characters managed to be both boring and unlikable.

I think you're grossly underestimating the cost of doing that to a fleet of vehicles sold with the promise of being self driving capable with the hardware package on board.

The President and Vice President are exempted from conflict of interest laws. The reason for this is interesting -- the Constitution sets out the requirements for being president, so the concern was that the laws would be challenged as unconstitutional and invalidated entirely if they applied to POTUS.

Of course, at the time presidents were in the habit of divesting themselves of their conflicts.

It's entirely possible they've overspec'd the compute in current vehicles. Give yourself 10-20x the compute you think you'll need, because the cost relative to that of the vehicle is still small. Optimize in future generations.

OpenCores probably has something. I don't know about RISC-V, specifically. On a semi-related note, I was surprised at how little area the ARM Design Start Cortex-M0 took up out of an Artix 35T. FPGAs have gotten big and simple CPUs are tiny :)

Two problems:

1) Typically shares are treated as ordinary income when they vest, so you owe tax on that no matter what you do (but the vest price becomes your cost basis).

2) Wash sale rules apply to grant vesting events, so if your grants vest monthly every sale is a wash sale.

I find it interesting to think about virtualization on a spectrum with passthrough at one end and pure emulation at the other. Particularly when applied to I/O peripherals, if the bulk of the I/O can effectively be classed as payload, stepping slightly away from passthrough while maintaining roughly the same layer of abstraction grants the implementer considerable liberties in implementation with very little overhead.

If one were to look at storage, specifically, the move to 4k block sizes would seem like a particular boon in terms of increasing the volume of data covered by any given IOP.

The current gen Xilinx stuff is pretty awesome. Digilent is even making boards aimed at the "maker" community: http://store.digilentinc.com/arty-a7-artix-7-fpga-developmen...

You can get Arduino type boards for a few bucks on Amazon, which can be pretty easily turned into an ICSP programmer for arbitrary other microcontrollers. That helps a lot. Even just using it as an Arduino if you skip the "IDE" is a great way to start.

I think this sounds like what the GP is describing -- they price above market to seek a higher than market offer. That they aren't inundated by offers simply suggests that the demand isn't there to garner that sort of premium. The market for houses in Silicon Valley is severely supply constrained, so sellers are able to demand a premium (that is, they could price well above what they "market" price ought to be and likely get offers at or near their asking price). It would set up a similar uncertainty in potential buyers minds that results in the absurd offers above asking that we see today.

Put differently: while the specifics of this sale (price well above asking) might be impossible in France, the "sale price well above rational market price" phenomenon is really hard to quash when the market chooses to be irrational for a while.

I suspect anyone ordering top-bin CPU skus by the pallet-load has an ongoing program for evaluating performance-normalized TCO of at least a few candidate platforms based around a few candidate processors.

Hand off to the secondary.

The ordering systems works fantastically given the volume, Prime shipping is huge, and their inventory really is broader.

The combination of (a) not needing to log in again to place an order (b) most things I'm interested in ordering being in their inventory (c) receiving most orders within 48 hours (and many within 24) is really potent. I've placed maybe a half-dozen non-Amazon orders online in the last six months, and apparently 163 with Amazon.

When possible, I avoid anything that's not fulfilled by Amazon due to point (c) above -- I'll find alternatives or even pay slightly more to get prime shipping.

Note that, in addition to Neal's instructions, you may want to load virtio_net with napi_tx=true

This makes virtio_net play more nicely with the qdisc layer. GCE requests moderately deep Tx queues 4096 -- without the module param you can have up to a 4096 packet delay between actual and as-seen-by-qdisc Tx times.

http://elixir.free-electrons.com/linux/v4.12.2/source/driver...

A related warning: your NIC driver can break the qdisc layer (or at least mislead it).

Prior to 4.12 the VIRTIO Net driver always orphans skbs when they're transmitted (see start_xmit()). This causes the qdisc layer to believe packets are leaving the NIC immediately until you've completely filled your Tx queue (at which point you will now be paced at line rate, but with a queue-depth delay between the kernel's view of when the packet hit the wire and when the packet actually hit the wire).

After looking at the code -- even in 4.12 enabling Tx NAPI still seems to be a module parameter.

(I'm not sure which other drivers might have the same issue -- my day job is limited to a handful of devices, and mostly on the device side rather than the driver side)

Yes, the Tesla would do that, at one point in Autopilot's history. Perhaps it still will, but for the past many months I have not had to disengage it in those types of scenarios, to the point that the car has reacted before I have, and this is with the previous generation of sensors. From a technical perspective Tesla has come quite close in practice in a three year old production vehicle to what Audi claims to be ready to ship. With the current generation of sensor package, I would not be surprised to see Tesla's vehicles achieve L3 in practice (not at a regulatory level) before the new A8 actually starts deliveries. My point being that Tesla's technology has taken quite a leap from where it was originally, even with the original sensor package. Treating what Tesla is shipping in software as a fixed point and saying "this would put Audi far ahead of competitors" (as the article does) misses what has allowed Tesla to make such rapid progress in the space: continuous iteration on the live platform based on data collected from their existing fleet across all conditions.

The system as described is considerably weaker than what my previous generation Model S actually does. On a highway with a barrier and traffic I can basically leave autopilot engaged indefinitely without having to correct it. Perhaps Audi handles a wider variety of weather conditions?

Risk.

Area 120 has bounded reward, but the downside risk is measured entirely in opportunity cost. If your goal is a quick sale, the upsides may be comparable as well.

One of the big things it glosses over is core counts... counting "servers" ignores that AWS has current-gen instance families with as few as 32 VCPUs in their largest instance type versus 128 VCPUs in the x1 family. If you look at multiple generations of families the difference between "servers" becomes even more stark.

That low tech limited screen time curriculum requires well trained (aka expensive) staff. Yes, it might have better outcomes, but it can't scale without an absurd investment that, so far, society has been unwilling to make. If you can raise the general standard of education at the same cost by going digital, that's still positive sum, no?

My observation is that the problems in software engineering tend to look simple until you actually try to build something larger than a toy. I gather that, if you have the relevant background in other engineering disciplines, the same deceptive simplicity applies.

It's easy to dismiss the difficulties that arise in software as properties of the language, platform, framework, etc. that you're working with, except that we're a few decades into this whole software engineering thing and we're still inventing (and re-investing) tools to solve "simple" problems. Which, of course, is also true in many other engineering disciplines. Sure, the scale may get smaller or larger, but base issues like "this problem would be easy if I could just temporarily disable gravity" or "I've got the perfect mechanism for this if we can allow one solid to pass through another when we assemble it" still crop up with remarkable frequency.

One might reasonably start to think that estimating the difficulty of problems is, in and of itself, harder than it looks.

If you have the degree of money to invest and you believe the expected the net return exceeds your other investments, you very well might make the bet.

We are, after all, talking about hedge funds. How much variance are you willing to tolerate?

Ironically, Java, which does have both, has a clear and unambiguous distinction between the two.

Having recently done some C development after a few years of exclusively C++, no, no thank you.

I'll take my RAII and destructors, thank you very much.

We're going with VAR-care and care as correct pronunciations of both, right? Asked as a native US English speaker.

Google's util::Status and util::StatusOr are actually quite flexible. While the generic error space is recommended for most work (and really, rather a lot fits in that space), it does support the notion of other error spaces like POSIX or Windows. At Google† I do quite a bit of interacting with the kernel, so my code makes fairly heavy use of the POSIX space.

That said, in the vast majority of cases any error I might be reporting from the POSIX space can be just as if not more usefully expressed (for the consuming software) using one of those ~15 generic codes. If their semantics are properly adhered to, those codes give good guidance on when an operation is guaranteed to have failed (but can be retried), when it's guaranteed to have failed (but cannot be retried without changing the request), when its fate is unknown, and when it has succeeded. In many cases this allows for generic error handling policies that fit a given application well. With enormous error spaces that is much more challenging.

In the cases where the underlying error deliveries clear value and I'm communicating across an abstraction boundary (I find the intersection of these is relatively rare), the Status type supports (albeit somewhat awkwardly) nesting. That allows the basic error to be one of the canonical types and the precise error to be communicated as a nested Status.

† I work on Google Compute Engine's on-host network devices and dataplane.

I worked there for a couple years, and I still live in Seattle.

If possible, I will not work there again.

It was not a bad place, but it was also not a good place. It took leaving (which I almost didn't do) to realize that second part. That's largely why I won't go back. There's a strong commitment within the company to the idea that you're part of something bigger, and that being part of that makes sacrificing comp, nights, weekends, and innumerable other things worth it. It was deeply satisfying in a local extrema sort of way.

Well, the post I responded to included a more or less textbook description of template based rendering. It's a response to a response to this:

> The bizarre practice of assigning session keys to visitors and somehow storing the page they're viewing in the server instead of in the URL is pretty common in Brazilian government, which is dominated by Java programmers.

Having dealt with such a service just today (King County Recorder's Office public records search) that behaves in this manner, I felt pretty familiar with what I was describing.

It is entirely possible I'd misapprehended the situation, but as it's an informal conversation on the internet about bad web development practices, I'm going going to dwell on it too much.