It works just like tar for the most part, so it extracts into whatever the current working directory happens to be. I'd just do (cd /other/dir; tarsnap -x -f whatever-archive).
This is already the approach taken with the operator overloading methods with single-method traits like Add, Sub, and so on. Arguably things like .abs() and .exp() also logically belong in the same category and therefore should be implemented as small traits of approximately one method each.
You can just give a chroot. At a company I used to work for, our build system used a chroot with a bunch of rarely-changing binaries/headers that let us build binaries for old distros, and then the directory with the actual code you were working on got bind-mounted into that chroot. The build process didn't depend on anything at all from the host system except for the build tool itself that set up the chroot environment. Everything to actually do the build (compiler, headers, utilities) lived in source control and was put into the build environment from there, so builds were 100% reproducible.
Also, by speeding, you are adding to the kinetic energy available to cause mayhem and destruction if you do screw up. And remember, kinetic energy is proportional to the square of speed, so going twice as fast means your car has 4 times more energy.
In California, the license plates stay with the car, and as people mentioned, there's a system to notify the DMV of ownership changes. Also, when you buy a new car, of course you have to register with the DMV and they mail you the new license plates... which takes the usual 6-8 weeks or whatever. In the meantime, you just drive the car around with no license plates.
One real issue with the nightly/stable split is that it hasn't been entirely clear when things will actually be making it into stable. I understand that software development is full of uncertainties and sometimes you just don't know how long an implementation will take until you actually build it. But right now, to someone not involved in developing Rust itself, it's hard to get an idea of what the nightly-only features are, where they are in the stabilization process, and when they might be expected to appear in stable. For a concrete example, I only found out that custom derive will be out in 1.15 because I happened to read Hacker News. And there doesn't seem to be any index of RFCs or where they are in the process at all, or at least not anywhere that I could easily find.
In the core team's defense, they're eyeballs deep in this stuff all day every day, so they have a pretty good idea about what is where and how far along things are. But us users who only glance at what's in each new release and only upgrade every 6 months would really like to know whether to bother to bother installing nightly for the shiny new feature or just wait for the next release that will have it and be actually stable.
> Whereas other manufacturers keep dedicated GPU framebuffers powered up even when using integrated graphics (because the display is connected to the GPU), Apple connects the display to a custom multiplexer so the dedicated GPU can be completely powered down.
I'm pretty sure it's the other way around: the IGPU does the displaying and the DGPU just does 3D acceleration. Other manufacturers don't have a hardware mux because hardware muxes are expensive, and instead have driver support for handing over rendered frames from the DGPU to the IGPU for display. Indeed, NVIDIA has actually made GPUs with no display hardware on them at all, intended for exactly this application.
The per-lot taxes you suggest are increasingly the way things are financed in California: it's called a parcel tax and when a city wants to raise money for schools and the like, it's one of their few options for passing a new tax, since they've already maxed out the property tax allowed under Prop 13. The other major option for new taxes is sales taxes, but those create a perverse incentive for cities to maximize the number of car dealerships and other commercial property and minimize the amount of new housing they allow, since it's stores that pay property taxes, while houses tend to consume more city resources while paying fewer taxes.
It's actually some combination of Apple and NVIDIA drivers, but on OS X, unlike pretty much every other OS, Apple insists on owning the OpenGL entry points and doing a bunch of work in its own driver before calling down into the vendor driver's OpenGL entry points. The vendor driver then has to undo some of the "helpful" things that Apple did, and work around whatever bugs are in the Apple code. For NVIDIA, in particular, the OpenGL driver is pretty much the same between Windows and Linux, and so one shouldn't be much more broken than the other, at least when it comes to core OpenGL functionality. But the OS X driver can't take as much advantage of the common code because of the Apple code that it has to deal with.
And of course Google and Facebook and the like don't really have a problem with rejecting 90% of qualified candidates, because "everyone" wants to work there and they have no shortage of qualified applicants. On the other hand, everyone that is imitating them has a rather big problem, because most potential candidates haven't even heard of their company.
For example, it is clearly easier to write a machine learning system to find interesting articles and highlight insightful commentary, compared to using something so crude as a group of people on a website collectively voting on which stories and comments they like... wait a minute...
It's annoying to sometimes have to introduce artificial blocks just to make the borrow-checker happy. It sounds like there's going to be some work done on non-lexical lifetimes though, which would solve the more annoying of these problems.
The planes talk to each other and run a common protocol that tells the pilots what to do to resolve the conflict. The problem is when one of the pilots doesn't listen to the nice robot voice yelling at him to DESCEND NOW!...
Because in a 3-bit flash cell, there are on the order of 10 electrons separating one charge level from the next. If a couple too many decide to quantum-tunnel their way to freedom, the bits will flip.
Sounds like I was right to pass on the company that promised me "4000 options" and insisted that any details beyond that were strictly confidential and could under no circumstances be disclosed to any non-employees. It seemed especially suspicious in conjunction with the rest of their attempts at hard-sell tactics that just left a bad taste in my mouth.
Not necessarily. It's entirely plausble that they set the price lower in order to boost the number of subscribers and thus their political constituency.
Unfortunately, Amtrak is desperately trying to give away its advantage on point 2. At many stations, passengers are not allowed to just wait on the platform and are instead funneled through a ticket check one at a time. This results in the predictable long lines, though the actual boarding process is still somewhat more efficient than on a plane.
Rust actually does a bit of this internally in the form of the null pointer optimization. If you have an Option<&T> (or Option<*T>) value, it's actually stored as a single pointer-sized value, with None being represented by a null pointer on the assumption that null is not a valid pointer.
Nice article. I just had a similar experience: after a bunch of work building a product, I came to the realization that the problem I was trying to solve just wasn't urgent enough, and the organizations I was trying to sell to just didn't have it together enough to decide to buy. So ultimately I decided to shut things down, though I did manage to salvage some of the code for reuse in later projects. Ultimately, entrepreneurship is an experiment, and sometimes what an experiment teaches you is that your hypothesis was wrong and you should try something else instead.
As a fellow landlord, I agree that checks are a giant pain. I'm actually working on making a mini-SaaS just for myself to use, using Stripe to handle ACH payments.
This actually happened in St. Petersburg, when they ran into difficulties tunneling under the river on Line 2. They ended up going under the difficult section, and now there's a 6% downgrade on that section of the line, which is pretty much a rollercoaster by subway train standards.
Plain old web forms are actually not so bad these days, since browsers are pretty good about keeping any entered text around if you accidentally hit the back button (or even if the browser or computer crashes). It's really the big fancy web apps with lots of stateful javascript that are a problem, since the URL doesn't necessarily describe the state of the page and the form fields the browser tried to preserve may not even exist anymore.
In the specific case I'm talking about, it was a big (and rather buggy) pile of stateful javascript, and whose failure would leave a crowd of angry sports fans and player waiting for it to start working again before the game could continue. In retrospect, not using in the the first place would probably have been the better option, but ripping out the backspace keys seemed like a reasonable compromise at the time.
Yep, delete button or else just use the default behavior of highlighting the full contents of the field to be changed. Mind you, these were dedicated machines that were specifically used for this one purpose and not something anyone would be using for, say, writing emails.
This is great news. For some use cases, backspace-as-back is a disaster waiting to happen, for example, in a complex web app used in some time-critical task and that requires occasional deleting of text but can lose state or take a while to reload if you accidentally hit back. If you hit backspace without having a text field focused, the whole thing dies and needs to be reloaded and possibly checked to make sure it's still working right, while hundreds of people are anxiously watching and waiting. I have seen laptops with the backspace key physically ripped out just to prevent people from accidentally triggering its back-button behavior.
Do you actually need a compiler that runs on those exotic systems, or just one that targets them? Because Rust (thanks to LLVM) is a whole lot better at the latter than the former, and it might well be possible to build something for your obscure UNIX. But for various reasons, Rust is not great at all at cross-compiling itself, so you would likely have to use something more conventional as your build server.
So was the piloting profession (in part because many pilots were ex-military), and yet somehow, that culture was changed to one of standard procedures, checklists, and Crew Resource Management. I'm still hopeful that the same can happen in medicine.