nkallen

Here is the model viewable in a web browser, for anyone interested https://share.plasticity.xyz/r/BDt8nFGQYVsdhi-v5SHSOn6jtBQUV...

don't sleep on shapr3d which is also very awesome

Mr Dildonic it's definitely not illegal, the poster is a troll

I agree with you -- it's hard to safely kill a runaway thread but it's not hard to kill a runaway process. But I think it's worth noting that the performance characteristics of IPC can be very bad

I appreciate your feedback and I totally want to market it in the way you propose. But let me be real: I am one person doing everything. I expect to have all that stuff by September when I plan to launch 1.0. If I were "in control" of this situation, I'd prefer the app get more buzz closer to launch rather than 6 months away. But I can't really control when people post to hacker news... And in any case I think all publicity is good. Dying in obscurity is the biggest risk.

When I get to version 1.0 I will do all of those things. For now this is a beta, more for artists who are interested offering feedback to affect the design of the app.

I think it's fine for people to have varying philosophical takes on what should be the normative goals of open source software licenses. Obviously the FSF takes a rather maximalist stance. I personally find this aggressive goal and some of the personalities behind it to not match my vibe. And the reality is that more permissive licenses like MIT are becoming more and more popular.

What I've seen some Blender plugins do to get around this is to have an open-source plugin communicate via IPC to a closed source library. It's totally legal. It's a performance and implementation tax that just seems silly to me.

It is for sure a murky area where I'm working out the details. You don't have the full kernel. But you can think of it a bit like a scripting API on top of the kernel, which is not uncommon in CAD apps, like OnShape's FeatureScript or something.

So external contributors can only provide patches without being able to test themselves I suppose.

My intention is that if you buy a license for plasticity, you can then build locally and test locally. You can contribute back or not depending on your interest.

Think of it like this. There will be a typescript/javascript wrapper around a limited version of the c3d kernel. this is the plasticity api. You will call plasticity.Enable(license_key) at the top of your program and you will be good to go. You buy a license key from me.

Although I do hope people will contribute the plasticity's development, my main goal with it being open source is that people will write plugins that they can then give away or sell themselves.

I have used commercial software that I pay for -- like Fusion 360 and MoI3d -- where I ran into bugs that I could have fixed for myself if only I had the code. I'm still happy to pay for them. Instead I literally waited 2 years for Fusion to fix a bug I cared about.

That’s exactly my take. What exactly constitutes a “derived work” in the gpl (plug-ins do!) is counter intuitive to me.

Even the lgpl definition of “dynamic linking” is something that scares me in the context of npm modules, which is why I’m nervous I made the wrong choice with lgpl

Please correct me if I’m wrong but I was not under that impression

https://stackoverflow.com/questions/5419923/can-gpl-be-re-li...

I thought I am the copyright owner and I can offer my code under as many licenses as I want. Many people dual license gpl code is my understanding. Converting my own code to mit should be allowed right?

Every Google result I’ve found says I’m the copyright owner and I can offer as many licenses as I want. Are you just trolling?

Yes that is correct. I am not ok with others.

Edit: Jesus do you really not recognize sarcasm? People are free to use whatever license they want and I’m free to explain why I choose lgpl over gpl

I will say I’m constantly bewildered by which license to choose. I’m using copyleft to defend myself a bit. But weak copyleft because I’ve hate that the gpl prevents blender plug-ins from being closed source or linking against something closed source. Plasticity will allow plug-ins to do whatever they want, that’s the goal.

There is some possibility I will switch to MIT since philosophically I’m more in that camp

Parasolid and Acis are the only other options. I have a lot of admiration for OpenCascade but unfortunately its functionality is very limited for my needs.

I’m considering parasolid but, no, I can’t keep this price point with it

I think the main thing to understand is that blender has minimal nurbs support. For example, try doing booleans, fillets, or offset surfaces with blender nurbs. You can’t.

Nurbs are good for some shapes and bad for others. In addition to manufacturing, nurbs are great for hard surface / scifi assets for video games and movies.

Plasticity is for artists. It is more in the tradition of MoI3d than say solidworks. It has a very powerful geometry kernel and the user interface is meant to be familiar to blender users and modern looking.

It’s still very beta and changing every day

I want to emphasize to everyone that this is for concept artists. It’s nurbs used to create interesting shapes and fillets. While there are some parametric features, they’re completely de emphasized compared to something like fusion or solidworks

This is a significant issue for anyone doing business with Russia. I’m happy with c3d in general but there is a possibility I will be forced to use another kernel

A full build from scratch would require the c3d headers, which I can’t provide.

What I am planning is to something like this: divide the app into two pieces, an npm wrapper around the kernel and the electron front end that uses the module.

You will need a license key to “activate” the node module. You would then use the electron app or the module directly if you’re a programmer. You will be able to build your own fork of the electron app, but not the npm module.

In effect you will be paying for a license key, not the binary

I wonder if you could handle backpressure this way, somewhat analogously to a thread-per-connection with a bounded number of threads. I don't think node.js API exposes the necessary functionality, but the point is that it's possible with callbacks:

  var MAX = 100,
      connections = 0;

  function continue() {
    server.once('connection', function(c) {
      if (++connections < MAX) continue();
      process(c, function() {
        if (--connections == MAX - 1) continue();
      });
    });
  }

  continue();

sam don't waste your time this is a joke

I know exactly what I would do in your situation.

Tell the CEO you need to go to Thailand for 8 weeks to chill out. Avoid quitting so that you can keep your Visa. Strongly consider going to your primary care physician (cheaper than a psychiatrist) and get on an anti-depressant. (This will hard to do at the same time as leaving a country as your doctor will likely not give you a two month prescription to start.) Bring your GF with you to Thailand for some of the time unless you are comfortable traveling alone. The travel experience may be enough to get you out of your rut, but I would get on an anti-depressant as well. Also exercise. Twice a week is enough.

Ignore anybody who tells you to "deal with it" or "subsist". There is more to life than your first startup. Learning to cope with depression is a lifelong process and isn't solved by just sucking it up. Also depression is not really a unique and beautiful snowflake of a disease. A change of scenery and anti-depressants will work 90% of the time.

I think it is fair to criticize Dispatch in the following sense: "is this a library you should use in production code?". I think the answer is no, because it has an API that, while terse, is difficult to read and maintain; and furthermore it pays very little attention to robustness performance concerns (like failure accrual and more sophisticated connection pooling) that quickly become important in production software.

Dispatch is a good example of a library that is more fun/pretty than practical for systems engineering -- which is not uncommon in the Scala community, as Coda rightly points out. It's not bad to be fun/pretty rather than practical, but it is right to criticize that (strongly) from an engineering perspective.

I'm biased, but: Finagle has a substantially more robust HTTP client and server library than Dispatch, and it has been stressed at far larger deployments than Dispatch. If you're writing a high-performance system that needs to make tens of thousands of HTTP requests per second, Finagle is a good choice and Dispatch is not.

There is no better time than during an outage to add these features. In my experience, band-aids are better way to resolve an outage than fixing root-causes. Make the problem go away by commenting out code, returning empty result-sets, (or whatever) - and re-balance your partitioned database at some later date.

Suggestion:

In additions to hiring scalability experts (many will claim to be experts but most aren't), talk to your investors to find outside technical advisors who have worked on and are still working on similar problems.

Find advisors from Google, Facebook, and other places who have dealt with these issues. In my experience, you have as much to learn from people who have made mistakes as from people who have succeeded.

Also, in my judgement, you guys are a little too risk-tolerant for your significance (first major Scala 2.8 upgrade, largest MongoDB deploy...).

Can you design the system such that you can turn off ("darkmode") features in an emergency? For example, in an emergency you can turn off badge-awarding as it is known to be RAM intensive (and degrade by seeking to disk).

To the extent that you do this across the board, you'll have yet another tool to defend against being over capacity.

Note that it's in the process of being released: it's as yet unusable by outsiders. Honestly, I did not expect this to make Hacker News so soon. :(

I have not used Neo4J first hand. It has really cool features, but it is not a distributed database and has expensive memory usage. FlockDB is distributed, uses little memory, and has a very limited feature-set that is highly highly optimized for OLTP. It's not really an apples/apples comparison. Theoretically, Neo4J could be used as a back-end data-store in FlockDB.

I think you've given a good suggestion for upcoming blog posts.

Gizzard is used by two systems at Twitter. One of them is called FlockDB and we are working on open-sourcing it (indeed, FlockDB is why we open-sourced Gizzard). FlockDB stores Twitter's social graphs. I cannot tell you (yet) how many QPS we do do or how many edges there are in the various graphs, but suffice to say its a lot and we run lots of complicated queries like "who follows both @aplusk and @oprah but does not want any of @aplusk's retweets," etc.

Gizzard is NOT perfect. But we think you'll find it is resilient to a large class of failure scenarios (that have, in fact, occurred over the last year, so this is not just the theoretical fault tolerance of a project that's been deployed on a small web site with simple requirements). With your help, it could be even better.

it's coming...

It's hard to come up with examples where idempotency is impossible (I'm sure there are some)... but there are definitely cases where it is difficult. Counters are one of the most obvious examples; to make them idempotent you need to jump through a lot of hoops. Usually you assign a transaction-id to each increment/decrement operation and you keep a log of which have been applied. Suffice to say this explodes the cost of storing a counter (which would otherwise only require 32/64 bits).

Other things are hard to make idempotent but it's stil practical. Examples of this include operations like "delete all rows matching query Q". This either means "delete all rows for now and forevermore" or "delete all rows that exist at time T". In either case new rows matching Q might arrive in the future (but be antedated to the past) and you have to store the operation around in some way to apply the delete operation in the future. This can be easy if your query is easy to represent, and there is a limited class of such queries.

Sorry, it's hard to be precise about this in comments. The bottom line is Gizzard is not perfect for everything but idempotency is worth jumping through hoops a lot of the time (Gizzard or no!)

Our uptime could use some improvement, surely. You will bear in mind that it has improved substantially over the last year. It's largely because of things like Gizzard...

I think one of the compelling things about Gizzard is that unending list of crazy and obscure failure conditions that cascade in unpredictable ways and take the site down--all of those that have occurred up till now are encoded into the design of Gizzard so that they do not occur again.

We have not fixed those "unknown unknowns", to be revealed in the future, that can cause a Gizzard system to crash. But my guess is that, over the last year, we have built in fail-safes for scenarios that exceed anything most people have ever experienced or ever will experience-- and by a long shot.

I love Cassandra, I think it's awesome. Twitter plans to move its Tweet storage to Cassandra. Suffice to say that Cassandra is young and the reliability of Cassandra with our throughput and our (very very large) corpus can use some improvement. Cassandra is not yet ready for production use at Twitter despite the fact that it has been deployed successfully at Digg and elsewhere. The Cassandra community is improving the database very rapidly. In a year or two I expect Cassandra to be a reasonable option for many popular web sites. But, even then, Cassandra's design has certain limitations that might prompt you to design a custom store (or consider alternatives). And indeed, there is a lot of stuff we have at Twitter that we have no plans to store in Cassandra unless there are substantial design changes.

An advantage of Gizzard here is that it is more flexible. You could, for example, build a document-partitioned inverted index with Gizzard such that you could do local intersections on each shard and merge these intersections in Gizzard itself. You might, in fact, use Gizzard in front of Lucene to do just this. There is no way to do that with Cassandra though perhaps they will build such features in the future. (To anticipate an objection, Lucandra is not document partitioned so it will suffer from fundamental efficiency problems for a certain class of search queries.)