bradleyland

Well, yes and no. Yes, when a single-source strategy is adopted, the spec is written for that supplier, but that does not mean that all cases where the spec is written with a specific supplier in mind are single-source bids. Sometimes it's an end-user trying to manipulate a bid so that only one supplier can answer. That's the distinction I'm trying to make.

Single-sourcing is a procurement strategy, not an outcome of RFP manipulation. When a purchase is put forth, the end-user[1] writes the specifications, and procurement staff[2] determines the procurement strategy. If the end-user can convince procurement staff that only a single provider can meet their needs, then they move forward with a single-source procurement.

When a specification is written specifically for a single vendor, it's not called single-source; although the end-user probably advocated for single-source during negotiations with the procurement department. Not surprisingly, this is a constant source of friction for procurement departments. End-users almost always want to buy their preferred solution, and especially in IT. There are often good reasons, but I digress.

In some contexts, the single-source procurement strategy is simply not available; usually due to procurement law. This is when you most commonly see manipulation of specification. However, competing vendors can challenge the procurement in court through a procedure usually called a "bid protest". That's not exactly what's happening here, but it's similar.

1: The person who will ultimately use/implement the purchased goods/services.

2: Usually a separate department responsible for ensuring that goods/services are "responsibly" procured.

> The problem is, in the current system, it's impossible to figure out who's doing it.

No, the problem is who is responsible for paying the fines. If the terminating carrier were responsible for paying robocall fines, this problem would be solved overnight.

But for some reason, the American people can't stomach this solution because we have a obsession with perfection in justice. The counter argument is, "The carrier isn't the one who is making the robocalls!" My POV is, that doesn't matter.

Unless carriers are obliged to participate in creating a network that supports compliance, law enforcement will always hit a brick wall when attempting to enforce existing laws. Carriers have been given _years_ to solve this problem, and in 2019 we're pitched STIR/SHAKEN... Seriously?

Make the problem more expensive than complacency and it will get solved.

> The authentication info is bigger than the call data required to set up a call.

That's not a counter-argument, it's a cop out. SSL negotiation uses more bandwidth than a vanilla HTTP GET request too, but sometimes a secure channel is more important than preserving bandwidth.

> Telcos with TDM or CDMA transmission have serious backwards compatibility problems.

More cop outs. In order to resolve problems, you have to make changes. You can't show up to the solutions meeting and proclaim that a problem can't be solved because "the old system doesn't work that way." Sometimes you must abandon the legacy systems to solve new problems.

In the US, voice time is rarely metered for domestic calls. Even discount providers offer unlimited domestic calling. The only case where you see metered calls is for pre-paid SIMs, which aren't very popular here, because you can get unlimited talk & text for $25/month.

This is hard to explain to anyone who hasn't done business with the Federal government, but your visions of national security letters are very much on one end of a broad spectrum. At the other end of the spectrum is the mundane.

The mundane includes things like contracting with the Federal government or even certain government contractors. Our company just contracted with PAE, and PAE contractors must agree to much of the same Federal Acquisition Regulations as someone doing business directly with the Federal government. One of the vendor forms was 37 pages long, and it contains sections explicitly requiring certifications that your company will comply with sanctions. The form binds the signer to personal culpability for failure.

So if you're a company contracting in this process you're tasked with preventing delivery of your product to Iran, and the Federal government gets to set the bar, not you. If you fail to meet the bar, you end up in Michael Flynn's shoes, only far less public. How long of a bet is it to expect a Federal bureaucrat will interpret compliance the same way you do? Are you willing to risk inquiry if your opinions differ?

I don't like what's happening here. I don't like it at all, but I know just enough about dealing with the Federal government that I can smell the odor from here.

Heh. Seems everyone has decided to shoot the messenger.

You may disagree with the policy, but ryaymercer isn't wrong. Living in startup land where everything is light, you move fast, and things get broken, it's very easy to overlook that there is this 500 lb gorilla in the corner just waiting to smash you into pulp for doing the wrong thing.

My guess is that something internally at Slack has triggered this. It seems likely that they're in the midst of contracting with a Federal agency, or something of the sort. When you do business with the Federal government, all manner of hell is unleashed on you in the form of paperwork and due diligence. "Negotiation" boils down to litigation, and litigation is god damned expensive.

I am not saying what's happening is right. I'm simply pointing out that this is the culmination of decades of policy and momentum within our government. Wagging our collective fingers at Slack isn't going to change a thing. What can Slack do? Let's say they pass on whatever opportunity is driving this ridiculous witch hunt. So then what? Some Federal agency doesn't get to use their messaging platform? Who cares? Nothing changes.

It all starts with asking the right questions, and ryanmercer's post likely contains the answers to a number of questions that few people are asking: what's motivating this change, who is responsible for the policy, and how can our community affect change to prevent it in the future?

I haven't commented in over 3 years, but you're the first person I've seen mention Vero Beach on HN in the 8 years I've participated. As a Vero native, your comment resonates.

Why would online cloud backup providers suffer because of a drop in SSD prices?

> Even with Time Machine backups, you still spend many hours setting configs after a restore.

But how many hours do you spend establishing, testing, and maintaining a backup plan that mitigates the risk of spending a few hours getting back to working status after a restore?

In my experience, TimeMachine is wonderfully effective at restoring system state (including things like shell customizations, dotfiles, etc). The marginal return on investment in more comprehensive backup setup just doesn't pay dividends. Of course, there's the issue of offsite backups, which typically aren't as comprehensive as TimeMachine.

The point I'm making is that technical folks often have a hard time making value judgements as it relates to technology. Having a backup of your data is 100% necessary. No argument there. Having a backup of your system state? That's not as high a priority, because you're mitigating a future time investment with a current time investment. You have to weigh the two against each other: time spent today versus potentially time spent in the future.

In the README, this description is given of the process:

"When the list of repositories has been compiled, it proceeds to gather all the filenames in each repository and runs them through a series of observers that will flag the files, if they match any patterns of known sensitive files. This step might take a while if the organization is big or if the members have a lot of public repositories."

Digging in to the source code under `/lib/gitrob/observers/`, you'll find `sensitive_files.rb` [1]. It looks like this class loads patterns from `patterns.json` [2]. This file contains patterns that match common sensitive files like private key files, common configuration files, command history files, and config files. It has the ability to match by path, filename, or extension.

No tool can look at a file and say for sure if it contains sensitive information, but this list looks like a good start for flagging common mistakes. I'm sure the author would appreciate pull requests to patterns.json as well.

1: https://github.com/michenriksen/gitrob/blob/master/lib/gitro...

2: https://github.com/michenriksen/gitrob/blob/master/patterns....

The phrase "sector defining" is commonly used to say that a car defines the target parameters of the sector at the time it is present. Not necessarily that that it was the first in the segment.

G.K Chesterton, All Things Considered

Light, but full of pragmatism.

The debate over whether mid-engine is superior to rear-engine is not an open and shut case. Although proponents of either camp would have you believe otherwise. The advantages of mid-engine are en vogue, so I won't repeat them here, but here are some advantages to a rear-engine car that are often dismissed:

Under acceleration, a rear-engine car has an almost absurd traction advantage over any other engine packaging configuration. For example, under acceleration, the 911 has a 74% rear bias, where the Cayman has a 67% bias.

Under braking, a rear-engine car has better weight distribution as well. Again, the 911 has a front rear distribution of 58/42 versus 64/36 for the Cayman.

I'm not nearly well versed enough in vehicle handling dynamics to hammer out a full-blown debate, but I have read very compelling arguments from both sides of the debate. I transisioned from the "mid-engine is the only compelling packaging format" camp to the "maybe the rear-engine format isn't completely insane" camp.

Good thing you checked Wikipedia :) I was just about to point out that VW Beetle motors had a smallish oil cooler in (or near) the fan shroud at the front of the engine.

That's true, but there are hard limits to the heat conversion efficiency of an otto-cycle internal combustion engine [1].

Given two engines, both optimally designed to approach those limits, air-cooling is not as practical or as efficient as water-cooling. This means that for a given displacement, you'll hit the boundaries of air-cooling before you will water-cooling. If you want to continue to increase your power for a given displacement, you have to find a way to dissipate the wasted heat energy. That leads you to water-cooling.

It's not that water cooling is that much more efficient, but that it scales more easily. With air-cooling, you have limited space around the cylinders for cooling fins. The head is particularly problematic because of the valve gear. With water-cooling, you can increase the dimensions of the radiator in three dimensions to improve heat dissipation capabilities.

1: http://physics.stackexchange.com/questions/98966/maximum-the...

No need. You can recover the public key from a private key using ssh-keygen's 'y' option:

-y This option will read a private OpenSSH format file and print an OpenSSH public key to stdout.

For example:

ssh-keygen -y -f id_rsa > id_rsa.pub

> Was it necessary to make the point as he did when he did? I don't think so.

Feynman was deliberate in his means of communication. Was it necessary? That's a tough one to answer.

As crazy as it sounds, causing your listener to be frustrated can be a very effective rhetorical device. Feynman's goal was to get the asker to think carefully about the question he had asked. Consider that, in a way, he was relaying his own sense of frustration to the asker.

Sometimes, in order to have someone truly understand you, it is necessary for them to shift their emotional state to one more similar to yours. The beauty of Feynman's explanation is that he hits the listener hard, then walks them back to a place of understanding. I thought it was a brilliant bit of teaching.

Was it necessary? I think that a short period of discomfort is a small exchange for a deeper understanding of not just how the physics of magnets work, but an understanding of how to properly ask questions, and just how deep the physics rabbit hole goes.

Congrats on the 1.0 release guys! We've been using Tabula since the days before the app packaging. It's been really cool to observe development progress, and especially to see you guys tackle the problem of distributing as an application.

The first time I visited the site, I really had no idea what I was doing. I'm going to write up my experience here for the benefit of the author.

I'll admit that I did not read the blurb on the landing page carefully. While that's a little embarrassing to admit, it's also typical user behavior. Users don't read; they scan. I did what a typical user would do: I scanned the copy and looked for the clicky-bit, and then I clicked it.

From there, I'm presented with a page dominated by two images. I tried to figure out what the hell I'm supposed to do.

Hrm... I see two obvious clicky-bits on this page: Agency and Porn buttons. The image over the Agency button looks pretty agency, and the image over the Porn button looks pretty porny.

What the hell am I supposed to discern here? Maybe I'm supposed to figure out which one is an actual image used by an agency or in a porn film.

I click my first answer.

Aaaaah geeze.

Fortunately, I'm on my free time and my wife has a sense of humor. She asks me to please close the door while baitin'.

"Fuck this, this isn't any fun," I think. And I close the window.

I drop a comment warning other HN users that they're going to be porn-audio-bombed by the site and move on.

A couple of days later, I notice that I've collected a few karma points and check my profile page to see what sage advice was deemed useful by the HN crowd. Heh, it was just my warning label and a swipe I took at Rob Reinhart that boosted my score.

I revisit the agencyorporn.com link, this time prepared for what awaits me.

Headphones? Check.

Smart kid who always reads directions attitude? Check.

Click!

Reading...

"Guess which of these tantalizing names belong..."

Names!? Wait, there's text on the pages?

I click the Start button for the second time in my life and I see what is clearly a camera and a dildo. Mkay, where's the "name"? I start at what I think is the top (the border of the two contrasting colors). Nope.

I really take a step back and start at the actual top. Holy shit, there it is. It's been staring me in the face the whole time! The text at the very top of the page is what I'm supposed to evaluate.

I try a few and quickly get bored with the concept (sorry). The audio also seems like it's leveled to be pretty loud. I'm kind of put off by the whole experience and I exit.

That's my experience as a user. As a product guy, my feedback would be this:

Users don't read.

If I'm supposed to focus on something, please make it the center of focus.

Users don't read!

Use visual hierarchy to communicate importance.

On the landing page, what is the most important element? Users are drawn to imagery before text, so the most important element on the screen is the image of the woman to the right. Secondarily, my eye was drawn to the Agency or Porn logo, then the start button. The instructions are the fourth most important thing on the page, visually. It's not clear that they are instructions. IMO, they should be labeled as such. The fact that they started with what appears to be a rhetorical question caused me to evaluate the text as a "blurb" (marketing copy), so I ignored it. My mind jumped directly to, "I'm already sold, give me the game!"

In the game interface, the visual hierarchy is out of whack as well. The item I'm supposed to evaluate is outside the visual grouping of all the game control elements. It looks like a page title, not a game element. Visually, the most important parts of the page are the two giant images. These images communicate (reinforce, really) the function of the buttons for "Agency" or "Porn". They are supporting elements, not primary elements. The "name" I'm supposed to evaluate should be the most important item on the screen.

This doesn't alleviate the walled garden concern entirely, but I've been kind of held up in my desire to try iOS development because I always felt the $99 ADC subscription was a silly requirement just to test an app on my own device. I've learned that with the next release of OS X and iOS, developers will be able to test their apps on their own devices using only an Apple ID; no ADC subscription required.

This is not an argument in support of Apple's approach. I just wanted to share what I'd learned about similar concerns.

If you have speakers attached to your computer, be sure to turn them down (or put on headphones) before choosing an item. You'll get a breathy, lusty sounding "Oh, yeah" when you click an item.

This is a great collection, but any listing of microbenchmarks needs a caveat.

Consider the first example, parallel assignment vs sequential assignment. As we can see by the results, parallel assignment is 2.25x slower, which seems like a monumental impact to performance, right? If all your application does is assign a few variables and exit, sure, but very few applications are this simplistic. In order to make a good judgement call on this optimization, you have to understand the impact within the context of your application:

What is the total execution time of your application?

What portion of that execution time is spent on assignment?

What portion of that execution time is spent on the extra allocation of an array due to parallel assignment?

At the bottom of the benchmark, we can see the iteration rate for each. Parallel assignment managed a rate of 2521708.9 iterations per second. We can work out the total execution time per iteration from this number:

Single iteration as a fraction of a second: 1/2521708.9

In decimal form: 0.000000396556478 s

Converted to milliseconds: 0.000397 ms

The same conversion for for parallel assignment gets us: 0.0001758783 ms.

In each iteration, we save 0.0002206782 ms.

Circling back to my list of questions, what is the total execution time of my application? If my app uses an I/O calls — and especially network I/O — it could be hundreds of ms. At this delta, it would take over 4,500 iterations of this optimization to achieve an improvement of 1 ms. If we're talking about an operation that occurs locally and is 100% in-memory, execution times may be <50 ms, at which point, you'd need around 2,250 iterations to get a 1 ms improvement.

At this point, I have to tattle on myself. This is an obtuse method of analysis. Microbenchmarks are hard, and at the i/s rate we're seeing here, there could be confounding factors that the author (and I) haven't accounted for. Things like garbage collection and object caching will have an impact at these time scales. Also, we have to ask whether our microbenchmark reflects reality? What real world application repeatedly assigns literals to variables millions of times per second? Extrapolating any meaningful decisions from the microbenchmarks alone is a fools errand.

The lesson is that microbenchmarks can only tell you so much. A comprehensive approach to optimization involves looking at the total run time and apportionment of time in an actual application. This process is called profiling, and the tools for profiling Ruby applications have improved in recent times.

Looking at the parallel vs sequential assignment difference, what you really want to know is whether parallel vs sequential assignment is impacting your application, and to what degree. Profiling tools will tell you where your application spends its time, and where it's allocating memory. This tells you where to look. Microbenchmarks will tell you which idioms you pay a penalty for. The combination of the two allows you to make smart decisions.

If you have a a parallel assignment wrapped in a loop that will execute hundreds of thousands of times every time your application runs, this will show up during profiling. Moving to sequential optimization will likely pay dividends. Otherwise, the penalty paid for parallel assignment is probably minimal. Profiling is a good way to tell the difference.

Your car is insured and is easily replaceable.

Car theft has declined precipitously in recent years. According to the NY Times [1], in 1990 there were 147,000 cars reported stolen in NYC. In 2013, that number had dropped to 7,400. On a per capita basis, it went from 1:50 to 1:1,100; a 96% drop. This dramatic reduction in theft cannot be solely attributed to an overall reduction in crime either.

This is not an argument for the status quo. I'm just pointing out that the principles being espoused in the responses here aren't axioms, they're value judgements. As software developers, we're taught to be hyper-paranoid when it comes to security, and we should be. That's how a culture of security is built.

However, in a broad sense, a balance must be struck. Like it or not, there is an acceptable rate of car theft, and that rate is non-zero. The acceptable theft rate is defined by what consumers are willing to pay to insurance companies to take on the risk and the assessment of the balance between probability and the anticipated inconvenience of having their car stolen. Consumer choices are defined by the alternatives, though. If the solution is that cars shouldn't have these features at all, can you find that car? What else do you give up in the process? Unless automakers ignore the problem, and theft rates skyrocket, buyers are still going to seek out these network enabled features because their convenience outweighs the risks.

Of course, it could be argued that we'll see a rise in theft again as criminals learn to use new technologies to steal cars. This has already happened in some places. BMW has run in to a couple of fairly high profile cases of this recently. In one case, attackers combined the easy accessibility of the ODB II port from a broken window with a security weakness in the cars software to bypass all the theft protection. No network access required!

The linking of the CANbus to network systems is too enticing from a consumer convenience perspective. That genie is out of the bottle.

1: http://www.nytimes.com/2014/08/12/upshot/heres-why-stealing-...

Sometimes the character limit delivers on its promise. Other times, it's as useless as posting a 30 MPH (50 KPH) speed limit on a six-lane interstate highway.

Hand washing dishes consumes massive amounts of water because people tend to leave the tap running while they wash. Laundry is typically done in a basin with a fixed amount of water for wash and rinse. I wouldn't place any bets that it uses less water than a high efficiency front loader, but I would venture that you can come close. Remember, we're not talking law of averages here. We're talking about a single person dedicated to the task of reducing water consumption.

The land fill presumption is still the safest bet.

The author said that he doesn't wash his clothes. By this we can infer that he brings his dirty laundry — for who knows how long — to a donation facility. I've volunteered at enough non-profit donation facilities to know that they don't launder intake. The expense is too high, and amazingly, most people don't bring in dirty clothes. If something is clearly not clean, it goes in to a separate bin for disposal.

Precisely. They might as well have asked them if they use TCP/IP. What percentage would answer yes to that?

At 1:56, it appears that the old motor suffered from the infamous valve-in-piston design flaw :)

If you enjoy hacking, do yourself a favor and get your hands on a small engine with a horizontal crank. They're harder to find than vertical crank motors, but much easier to run on a bench and more closely resemble a car engine. Take it apart and put it back together again. If you're not going to put the engine back in service, there is very little you can get wrong. Don't worry about torque specs or gasket quality. Just get your hands dirty! It's great fun.