brianshaler

The XPS13 has a hiDPI screen. Hardware wise, the screen definitely seems on-par with MBP but on the software side, it's a little infuriating encountering applications that don't support hiDPI. Instead of those apps just looking blurry like when OS X introduced 2x resolution, they show up at native resolution (50% of normal size)

But who knows, maybe I missed a setting somewhere to correct that.

Thanks! I haven't read every word of the GPL and hadn't heard about the written offer to provide source code bring a requirement.

That's only half of the problem, as I understand it. Also unacknowledged was that by distributing an app that is comprised at least in part by GPL code, they are required to provide the source code for the app, not just any changes they made to the component itself. Granted, it seems like refusing to provide the source code when asked for it would be a violation of the license, as opposed to actively distributing it via GitHub.

At least that's my interpretation of GPL requirements.

Standard Node.js, Javascript, and npm vitrol aside, I think this post covers an interesting topic of balancing progress with stability. I'm sure everyone has their own opinion on what is too fast (breaking things) or too slow (lacking modern language features and engine improvements), but the model they describe seems to do a pretty good job of appeasing both agile and inertial clients.

Still, a rapid release cycle for the engine could wreak (and to some extent has wreaked) havoc with the npm module ecosystem not keeping up.

"They just pocket the extra" is another way of describing a business' profit margin. The point here is in order to pocket enough extra to stay in business, they need to increase prices in order make up for the additional cost of credit card transactions.

They don't and can't give you a solid 4% discount for cash payments (or a credit card surcharge) because it is generally against the terms of their merchant agreement and they would be at risk of losing their ability to process credit card transactions altogether.

My original comment was merely reflecting on the fact that the perceived upside of getting rewards is dampened by increased costs that are passed all the way back through to the consumer anyway.

> We get the reward points with none of the drawbacks.

A small nitpick would be that there is a drawback: the cash value of the reward points is less than the additional cost of doing business for the merchants you pay via credit cards. Granted, if everyone else is using credit cards while you use cash, you get hit with that drawback without the benefit of recouping a portion of that value by way of points.

What about bridges and tunnels? It seems like an ideal (or idealistic) solution is to clean up the source data to include intersections when there are intersections so they don't have to be inferred. Is that impractical or would it explode the size of the dataset?

That's still the same argument. It's possible Martian life has already been decimated by microbes from earth, but does that possibility justify carelessly introducing new extremophiles? There is a short window, less than a century and perhaps only a couple decades, before we start sending humans in which we can study what may have lived on Mars, originating from there or not, prior to colonization.

Conley is not trying to prevent Mars exploration or colonization. When we contaminate Mars, we should only do so as a deliberate choice, aware of the consequences, as there is no going back.

I think of it as a poorly designed DSL. Still, a poorly designed DSL, once memorized, is way more practical on the command line than typing out javascript function calls, even with the fat arrow syntax. Maybe it's a declarative vs imperative kind of thing. I hate having to reference manpages or use trial and error every time I need to sed/awk, but I don't know if wrapping commands in JS functions and results in Array.prototype is the best solution.

It's hard to be sure of anything there.

While the conclusions in the article may not stand on their own, I think he may be implying the common usage of web browsers in the DPRK. Rather than using DNS, users connect directly to 10.* IP addresses.

Here are a couple of pics I took of IP addresses printed on the walls in a school's computer lab:

Portal: http://i.imgur.com/MTYlNVo.jpg

Bookmarks: http://i.imgur.com/QWEooy5.jpg

A sizable chunk of that is probably database indexes.

I would assume searchability. A non-case-sensitive non-regex search of a codebase could yet false positives for things like "autoDot"

I wasn't expecting to see familiar names in this thread. I remember when you started OS! Fantastic to hear it's going so well.

The author did an excellent job of getting into their heads in the situation and rationalizing their decisions. They underestimated road conditions; "their pamphlet offered an (erroneous) alternative, apparently shorter route back down to the valley in the form of a road down Anvil Canyon;" they made an easy-to-make wrong turn; and they were operating under an assumption that help was a few miles south instead of dozens of miles back.

"Given the information available to them, where could they best find it? It is likely they had gone the entire day without seeing another human, so their entry route offered little hope of others. In examining their maps, Ballarat was many miles away, and with unknown services. Furnace Creek, with everything they needed, was far to the north, out of their reach. Even the paved Badwater Road on the valley’s east side had only intermittent traffic and was in a zone of lethal heat. But there was another possibility... [only about 8 or 9 miles to the south of them]"

I think the point was that an Android app that needs to send a notification to a user of the app should use the built-in push notification functionality.

You can express your disagreement with staying past office hours without being condescending. Though, the post only indicated no participants were allowed to work past a time, not that everyone must work until that time.

I've been surprised/impressed by their quick and painless limit increases. It makes sense to have low default limits so people don't accidentally spin up a thousand instances or send a million emails. It seems the limits are mostly there to protect you from a bug or test in early development costing you a bunch of money.

What about h1 = React.DOM.h1;?

Personally, I moved from using DOM tag names as variable names ('a' being the worst) to saving 'var DOM = React.DOM' (or '{DOM} = React') and then calling DOM.a(props, children...)

I agree that with mobile, latency is usually a far bigger factor than throughput when it comes to perceived speed. I would also wonder if, once the image is downloaded, what the performance cost or benefit would be of more compressed images. Are they faster due to a smaller footprint? Or are they more costly to the CPU to decompress? (I would assume the former for JPG, while the latter is often the case with video)

What they did was super impressive, and is a fascinating way to figure out the optimal global compression settings. However, I got my hopes up that perceptual image compression might be about computer vision. At scale, analyzing every image would obviously be prohibitively expensive, but it would be amazing to analyze the detail/edges or color usage (e.g. how much red) in a photo, and tune the q & chroma values accordingly. That, or compress with multiple settings and analyze the resulting images for noise introduced by artifacts.

I assumed that's what the video in the article was about [0], but I haven't watched it to be sure. Is there anything in particular that isn't clear from the article? Or are you asking about docker security concerns beyond what this article is about?

It seems the main point is if there is any way to exploit code running within a container that has unfettered root access to the host system via the docker socket, an attacker would then have complete control over the host system.

Exploitation is often mitigated in layers, where if Service A is exploited, an attacker can only rwx what and where Service A has been granted priveleges to rwx. That should be as little as possible, the bare minimum access that service needs to operate. There's no reason your web server or database should be able to install new programs, create users, etc.

If Service B is running in a container and is given access to write to the docker socket, suddenly any exploitation of that service opens a door to immediately have full and unfettered root access to the host system.

> [0] FTA "... ended up making a screencast to unambiguously demonstrate the flaw in their setup..."

I appreciate the detailed response! My use case is yet another indie web, run-your-own-server kind of thing that processes content my friends post online (from tweets to shared articles) and can predict whether or not it is relevant to me based on extracted topics, source, my context/location, and whatnot. Both the source data and training data comes in at a trickle (though I'm pondering ways to propagate training data throughout friend-of-friend networks) and is processed in the background rather than on-demand, so my performance characteristics are very different than most of the use cases I've seen.

I'm trying to keep the system frugal with memory but liberal with persistent storage, since you can run a commodity instance 24/7 and mount a pretty large volume for fairly cheap. It'll be slow, for sure, if there's only one user for each installation it won't need to worry about handling many queries per second.

Not having dug through the code or documentation yet, I'm curious if anyone else knows if this can be used with a minimal memory footprint. The home page touts performance with everything in memory, which is great for blasting through a dataset and then spinning down a $1/hr server. What if I'm willing to accept orders of magnitude slower processing to run this full-time in the background of a low-memory server?

Couldn't orders of magnitude more people use a single piece of infrastructure? I think their point was you could live and work anywhere then go to the one station in the vicinity for a couple minutes once or twice a week to top up.

It helps me visually understand and debug bitwise operations. I suppose you could also compare inputs and outputs by printing the resulting integer as binary text, but I've always just used my hands.

It can also be nifty for ASCII conversions, as letters A-Z and a-z are the numbers 0-26, but with different prefixes (010 and 011 accordingly). This means you can read people's binary tattoos.

The same could be said about other types of abstractions, such as using a compiler versus assembly. In the vast majority of circumstances, developers get far more accomplished using higher level abstractions and frameworks.

In very extreme circumstances, portions of an application may need to be rewritten at a lower level for optimizations, but that doesn't negate the value provided by abstractions that allow the developer to be more productive expressing higher level concepts while the computer handles the tedium of how those concepts are translated into machine code.

My github profile email is different from my git author email. The latter is even more accessible. Just run git-log on any repository an author has committed to.

Re-opened to test in Chrome on Ubuntu (XPS13dev) and to my astonishment, touch events worked!

Could you make a compromise and agree that the terms were ambiguous enough to make people feel uncomfortable or uncertain about whether or not it was safe (or felt safe) to architect an application on top of software whose license could be revoked without wrongdoing? That would not require the terms be legally enforceable, thus a debate on validity could be considered moot.