It should be possible to do that using one Ethernet port using VLANs. You could buy a cheap L2 managed switch and use it to trunk two different Ethernet networks on the same port. Then you would configure the Linux networking stack to split the VLANs into separate interfaces.
I am by no means a networking expert and was able to use technique to work around a similar issue in the past. It was easier than I expected!
SIGBOVIK is a parody of computer science conferences. It's a running joke hosted on April Fools Day every year at CMU - and apparently a quite convincing one. ;-)
Source: I attended SIGBOVIK a few times in grad school.
As someone who lives in Pittsburgh - and likes the city quite a bit - I can attest to the fact that: (1) the weather is rarely perfect, (2) the entire city is under perpetual construction, and (3) the lines have not been painted in years. It took me quite some time to comfortably drive in the city because to the narrow streets, poor road maintenance, and bizarre traffic patterns induced by the many bridges and tunnels.
It will indeed be interesting to see how the well the Uber deployment goes in practice. They certainly did not choose an easy place to start.
Concepts, modules, a file system library, and an asynchronous I/O library have all been discussed as additions for C++17 and beyond. Most of these features are standard in modern languages. I would not consider any of these to be "scarcely useful." As someone who uses C++11 on a daily basis, I very much look forward to using these features without a Boost dependency.
That being said: I don't think that a graphics is a good addition to the standard library. It would tremendously difficult to standardize this for the reasons others have mentioned.
I had this issue fixed on my mid-2012 15" rMBP. It's known issue with some of the early LG panels on that model. The technician at the Apple store ran some standard image persistence diagnostic script to replicate the issue.
They replaced the display for free outside of AppleCare. I didn't have to argue with them at all, so I suspect that this is their standard response. YMMV if you have a newer model.
The bitfield example is misleading. Section 6.7.2.1/10 of the C99 standard says:
"The order of allocation of bit-fields within a unit (high-order to low-order or low-order to high-order) is implementation-defined"
There is no guarantee on the order of the bits inside a bitfield. The compiler may also introduce padding, e.g. for alignment purposes. This makes bitfields unusable for unpacking binary data.
Unfortunately, you're stuck with shifting and masking to replicate the same effect.
Why would you not use A* from the beginning? It's a trivial extension to Dijkstras and is often orders of magnitude faster when an informative heuristic is available.
Also, both algorithms require identical data structures. After all, Dijkstras is just A* with a zero heuristic.
I do agree about the constant factor, though: it's likely that a binary heap would be faster on most data sets.
Unfortunately not. Matrix inversion (or any type of linear algebra, really) deals with real numbers. This problem is nearly a linear program, which can be solved very efficiently, except that some variables are constrained to { 0, 1 }. As a result, it's an integer program, which is NP-hard. Intuitively, this is hard because there are no derivatives (e.g. gradient, Hessian) to exploit in discrete optimization problems.
One heuristic is to solve an IP is to relax the integer constraint to inequality constraints, solve the LP, and round the results. However, this can do arbitrarily poorly on most problems.
Matlab is much faster. For a sense of scale, a relatively simple image processing script ran 125 times faster in Matlab than Octave. This is, most likely, because Matlab has a better code optimizer.
I don't see a compelling reason to use Octave unless you're trying to avoid paying for a Matlab license. If you're going to switch tools, why not switch to NumPy/SciPy and get the advantage of using a full-featured programming language?
It's not that uncommon in CS. I just started a Ph.D. program (Robotics at CMU) straight out of undergrad and a decent number of the other incoming students are in the same boat. It varies depending upon the field and the university. For example, several of the top mechanical engineering programs require a M.S. to apply for the Ph.D. program.
I doubt it. The article makes this sound pretty specific to producing the magnetic disks used in hard drives. I don't see any reason why this would also work for silicon processes.
It works, but not as well as in OS X. At least as of ~6 months ago, the Linux drivers for the MBP/MBA multitouch trackpads were unpleasant to use. Everything nominally worked, but the user experience was terrible: e.g. the palm detection was worthless, so the cursor would jump around the screen as you typed.
There are also a plethora of smaller problems: it's not possible to switch between integrated and discrete GPUs, power management is abysmal, Thunderbolt support is non-existent, etc. If you include the new rMBP, the problems are even more severe (i.e. you have to jump through a ridiculous number of hoops to get wifi and graphics drivers installed).
To be fair, some of this is Apple's fault. However, that doesn't matter to the person trying to run Linux on their laptop.
[Edit] To be clear, all of my development is on Linux. I prefer Linux to OS X for many reasons, but drivers is definitely not on that list.
Just a guess: The weaker gravity (around 1/3 of Earth's gravity) makes it much easier for wind to pick dust off the ground. Once a dust storm starts, it would also take a lot longer for the cloud of dust to dissipate.
Look at the videos of astronauts on the moon from the Apollo landings. Everything they do kicks up a significant amount of dust that takes quite a while to dissipate. Obviously it's not a perfect comparison because the moon has weaker gravity and a different composition.
That description states a resolution of 1920x1200 instead of the 2560x1440 on these panels. I think 1920x1200 looks pretty awful on a 24" monitor, so I'm sure it will look even worse on one that is 3" larger.
It's a shame these monitors don't have an HDMI input. Then again, I can't complain given the price.
Depending upon how this evolves, it could cause legal issues for employers who make postings. It's illegal to discriminate by a lot of personal information such as nationality, age, race, whether they have children. All of this information is quite obvious when you look at someone's Facebook profile.
IANAL and don't know enough about employment law to know if this is a legitimate concern. It doesn't sound like this is a very serious effort ("Facebook had a third-party developer create the new site"), so maybe there's nothing to be worried about.
I am by no means a networking expert and was able to use technique to work around a similar issue in the past. It was easier than I expected!