ajamesm

No, that doesn't constitute implicit moral approval. We all understand that platforms and providers can't police each individual user. That's a concern about logistics, not moral consistency.

That said -- there are products that Shopify does (and would) kick a user for selling. Shopify isn't neutral, in fact, they're saying Breitbart is acceptable.

They frame it as "imposition of morality" though the issue is broader than that, i.e. Breitbart's tendency to incitement and spreading disinformation.

Crying "free speech" over issues of incitement or violence is the bread-and-butter of the alt-right, and I'm deeply curious as to why Shopify decided to employ that tactic.

> In a way, my position is an appeal to preserve some of the gray in the world. All solutions necessarily have to come from the middle ground.

This is bankrupt, morally and intellectually.

As someone who owns a couple rental units, the prospect of being a rent-seeking gentrifier or a slumlord

Lmao, if you paid $10 you got ripped off.

Genuinely lmao at the narrative that the taxi unions all got together and conspired against greener rides

yeah, real shame that the unmitigated sexual harassment got in the way of their complete avoidance of regulations

You send a message to [the person who can prove ownership of HN username 'perfmode'].

c.f.: https://keybase.io/docs/kbfs

  Soon, you'll be able to throw data into /keybase/private/yourname,pal@twitter,
  even if that Twitter user hasn't joined Keybase yet.
  Your app will encrypt just for you and then awake and
  rekey in the background when that Twitter user joins
  and announces a key.

Companies that grant options could fix this in a heartbeat by extending exercise windows; they choose not to do that. Nothing to do with AMT here.

If AMT repeal would 'fix' stock options, companies will change the terms to 'break' them again because they are handcuffs, not payments.

Nothing says "normal demands of everyday life" like bouncing quarters off of bedsheets

You'd... know if it was him. He'd, uh, have some choice words about Bomb Man.

I was most surprised by this CEO who goes around messaging randoms on LinkedIn to start friendly conversations. Does that happen?

70x faster? If Crystal gets its own port of Ruby on Rails, oh boy.

If you're a tech company, and your stack is so tightly coupled to Amazon that it represents an existential threat to your server fleet, you were never going to make it anyway.

Wal-Mart, probably. They bought Jet.com, which is effectively Amazon retail. I've tried it and it works just fine.

Amazon's definitely the 900 lb gorilla of convenience, but the BATNA of simply not using them is not really a material concern for the normative middle-class consumer who can drive to Target.

Off the top of my head -- protobuf, thrift, avro, XML, lua tables, properties files, yaml.

Heh, people sure to use it like it's the answer to everything, and "don't use it" stops being an option if you're writing to a JSON-based interface.

JSON's fine if you don't have any requirements around data serialization and you want it to "just work" for your webapp, but there's a lot of tech debt inherent in it.

So you dump a report in JSON format and back it up to S3. S3 costs are growing faster than you thought, so you gzip deflate all of it. Everyone has to go patch their JSON deserialization to detect gzip extensions. Whatever, just growing pains.

Then another team tries to read the reports, and they're getting errors because your definition of an interface is "we'll just use JSON, the keys are human-readable".

You define a formal API for your report format and in doing so you realize the need for versioning attached to your report schema, so you wrap all your JSON objects with types and version annotations. You could define a central repository for these schemas, but it's easier to just bake them into the top-level response. Everyone agrees that this is "lightweight" and not "centralized".

Now you're storing reports where each sub-object has its own annotations, or you're defining an entire schema at the object level. Object deserialization is taking 200ms even for small payloads, because of all the validation callbacks you're firing, and developers are now "performance hacking" their components by disabling validation callbacks. Now you have all the space overhead of schematic annotations with none of the benefits.

In order to adhere to the API, either teams are writing separate serialization libraries, or you form a team to maintain them as infrastructure, which is a great idea except that the horse already left the barn 2 years ago.

Without even realizing it, you've reinvented XML and XSD. And I don't really like XML either but at least you have to be honest about what you're getting yourself into.

s/CIA/arbitrary third party/

Headline makes it sound like the Cisco routers come with a CIA SSH key baked in.

facepalm Thanks.

Yeah, private equity is a natural response to business failing in the wake of a bubble, but bubbles themselves are market distortions caused by insane valuations.

Highlighting the value of reclamation just draws the heat off of the irrationality of the tech bubble. Amazon isn't a rich ecosystem, it's oligarchic.

And, indeed, any systemic failure in a capitalist economy gets explained away by saying that some cadre of vultures will exploit arbitrage until the gap closes. No one really questions the systemic failures per se. The economy happily creates this surplus in full anticipation of it being scrapped and fed to vultures. Banks repossess cars and capitalists think "working as intended" instead of "there's so many delinquent car loans that there's an industry of repo men and maybe that's significant." This criticism extends similarly to the tech bubble.

I'd almost pay a premium just to AVOID branding associations with Bono.

All this needs is a "This is good for Bitcoin." and we've reached full success-fail.

In that case, I guess we're just drawing from different glossaries. I've always heard "blocked" used to mean "can't execute because of something other threads are doing" regardless of whether that's starvation or getting slept by a mutex.

  In this post, I will summarize my understanding of a non-blocking (lock free) design of linked list data structure...

The author conflates blocking with lock-free. Starvation is a form of blocking, non-blocking implies no starvation.

You realize you cherry-picked a snippet of my post, and then made the exact point I just made, which is:

There aren't deadlocks, but there is still waiting and potential starvation, all of which can be informally called "locks" and so we need to be careful about qualifying "locking".

This isn't a criticism of lock-free methodology, but a consideration of the ways in which "lock-free" could be interpreted.

Oh god, "non-blocking" is even worse, no thanks to Javascripters. Lock-free data structures can wait, and can block if they deal with failed operations by spinlocking.

The muddled concepts are: waiting - what you do until you eventual acquire a contested resource (spinlock) mutexes - objects used to enforce critical sections stopping the world - a processor stopping the execution of all threads in order to ensure proper order of thread-critical instructions (is there a formal name for this?) CAS - an atomic primitive often used to avoid the overhead of stopping the world to enter critical sections, or to avoid deadlock by implementing algorithms that do not have critical sections critical section - a routine that must be executed by only one thread at a time blocking - being unable to proceed with a given routine on account of another thread non-blocking / async - threading in general, or, instead of spinlocking, yielding execution to another thread deadlocking - a systematic failure wherein there is a cyclical dependency of threads on resources, and no thread can progress

All of these can be informally referred to by "locking", and lock-free (formal definition) algorithms avoid deadlocking by avoiding having critical sections or locks on resources at all. They're generally more performant, but that's coincidental.

If you have a critical section, and you implement a mutex using CAS, you've probably sped up your application because you no longer have to pause other threads. That's "lock free" in the sense that "stopping the world" is "locking" other threads, but not "lock free" in the sense of avoiding deadlock. If a thread enters a critical section with a CAS mutex and then waits forever, you can get deadlock.

The linked list discussed in the article forgoes mutexes, but in exchange, operations aren't guaranteed to succeed:

  Because we are no longer taking explicit locks,
  there is no guarantee that insert operation will succeed.
  Therefore, CAS based algorithms are usually implemented
  using a loop (aka CAS loop) to retry the operation when
  CAS fails.

So you're still getting spinlocks (or context switches, etc.) assuming these inserts have to eventually succeed. Implicitly, the CAS does "lock" in the sense of forcing other accesses into retry loops. You're still dealing with the problems inherent to your waiting strategy. This data structure doesn't prevent problems like starvation. In the pathological case, you'll get stuck forever in a spinlock trying to insert.

> In some sense, this is the critical reason that CAS and lock-free programming is interesting

Right. The article's preface criticizes implementations of mutexes in C++ and Java as unscalable, which is certainly a problem, but categorically a different concern from that of designing lock-free algorithms or data structures.

Right, I think you looked past what I said, and why I put "lock free" in quotes:

> I don't like usage of the term "lock free" to mean "locks that are less costly".

There's a difference between being formally "lock free" meaning "the system is guaranteed to not globally deadlock", and this informal use of "lock free" meaning "CAS is more efficient because it doesn't block execution of other threads in obtaining a mutex"

This article's intro:

  Data structures (and their corresponding methods) implemented with coarse grained locks
  are hard to scale in highly parallel environments and workloads where the structure is required
  to be accessed by several concurrent threads simultaneously (parallelism).

is talking about performance, not termination guarantees, and that muddles the meaning of "lock free".

I've only ever heard that with "lock" being qualified as a deadlock, not a synchronization primitive.

So if solar flux is zero-sum, then farmers are appropriating sunlight that would otherwise be productive in other ways. All they're doing is using carbon as energy transport, not "creating" anything per se.

What I'm saying is your idea is insane.

I don't like usage of the term "lock free" to mean "locks that are less costly".

There's a difference between (A) locking (waiting, really) on access to a critical section (where you spinlock, yield your thread, etc.) and (B) locking the processor to safely execute a synchronization primitive (mutexes/semaphores).

CAS is "lock free" only in the sense that it doesn't require the processor to stop the world in order to flip the mutex boolean. It's still a mutex, and it still gates access to a critical section, and you still need some kind of strategy to deal with waiting for the critical section to become available (e.g., spinlocking, signaling the OS to sleep thread execution).

  An example of operation using coarse locks would be a method in Java with “synchronized” keyword.
  If a thread T is executing a synchronized method on a particular object,
  no other concurrent thread can invoke any other synchronized method on the same object.

That's just putting one giant mutex around all access to the object. Having finer granularity != "lockless".