rantanplan

Everything you said is just spot on. Every single word is like exactly how I feel about the show.

I have no clue why you're getting downvoted.

>That's an urban legend.

ROFL. What are you talking about?

You're talking as if it's a solved problem for all cases. Hint: it's not.

If it was an urban legend people wouldn't write dissertations on it.

> What makes the system great..

Excessive capital accumulation is what makes this system great?

Do I read that correctly?

Ok, although I didn't get the part about "eating out at restaurants with people who are too fussy about their food".

Are there adults out there who are fussy with their food? In what way?

That makes sense(especially about the germs paranoia).

Your logic has many bugs.

What's wrong with just explaining that they shouldn't eat stuff from the ground. Period?

It creates, exploits and maintains vulnerabilities in public infrastructure that anyone else(state nation or similar capacity) can take advantage of.

> it generally draws the line at knocking services entirely offline

Well if you're gonna play the card "I'm reading a different Internet than you are", sure whatever.

I don't think it's going to compete with anything. Pretty much everyone supports(and if not they will) Wayland, so maintaining and supporting Mir will become moot.

One of those things that you really can't understand why they sink money into it :(

To that I agree. I wasn't talking so much about startups. Admittedly a CEO(quite often a founder) there plays a much more instrumental role.

I would characterize most CEOs I've met(and not only) as decorative. And that's why they do get replaced in an instant.

We're just used to CEOs having only a decorative role, who can be replaced in an instant. So much so that when we see a CEO actually working/engaging with the actual product/service, they seem like a peculiar and rare specimen.

> Add that to the fact that the US has a lot more to lose if it gets caught attacking internet infrastructure than China and friends do (even just tests like this) and I would be surprised (honestly not shocked, but definitely surprised) if the USA is behind these shenanigans.

So can you give me the address of the rock you've been living under for the past 3 years?

Well, yes I agree to everything you said.

The designers must always collaborate with the engineers, if that's not happening it's bad project management :(

I also approve your tech/engineering choices :D

That is interesting. Which parts of the process would you want to be involved in, and why would it make such a difference in the time needed for the delivery of the feature?

Yes let's not over-analyze this.

Obviously an engineer is involved in the shaping of the requirements by interacting with the product manager or whoever(never the client). By asking questions, making inquiries and sometimes even poke holes into user stories that ultimately don't make much sense.

No one is all-knowing, no requirements are perfect, etc etc.

What I'm saying is that it's the job of the (Product) manager to understand what the client wants and to relay this into more tangible terms to the engineers.

As for knowing the business domain. Meh, sometimes maybe, but I can think of myriad of situations that it doesn't matter and it may not even make sense.

If you have dozens of engineers and you expect all(or most) of them to be familiar with the business domain, I'd suspect there would be some serious management/organizational problems in that company.

Technical specs no, but well defined product requirements definitely yes.

I'm fine with engineers fleshing out the technical specs(who else is gonna do it anyway?), but requirements come by engaging with the stakeholders, as you said, most notably your client(s).

And this is not a job for your engineers.

As a profoundly good liar, and a Greek, I can assure you they are not. Trust me ;)

For some reason they created a character who's Armenian with a Greek name(Stavros).

Some kind of bad research I guess.

I would be interested if you could elaborate a bit.

> Right now, PyPy is probable the biggest reason why many users don't migrate to Python 3 yet

I've met hundreds of pythonistas, in all sorts of different places. A lot of them wanted to migrate to Python 3.X not a single one told me that PyPy was a reason.

> They are calling because they want to sell you like a piece of meat

Compared to..... what?

Calling me because of my good-natured character and my unparalleled virtues?

The single machine shouldn't be the deciding factor.

If your application is like most apps(far more reads than writes) then you can easily distribute the load across multiple machines. If you have more writes than reads(quite rare but still) then scaling an RDBMS will be challenging.

In this case, if eventual consistency is something you can live with, a NoSQL store might be best for you.

FB and all big companies are a very bad example. They have ton of resources and usually they don't use vanilla products, since they have the engineering capacity to support their own forked versions. e.g. see their own version of PHP.

Also distributing reads is easy, writes... not so much. NoSQL systems usually offer distributed writes with the caveat of eventual consistency. RDBMS have referential integrity and other constraints which by definition cannot migrate into a distributed environment. Or at least there's not a one size fits all solution.

> Distribution comes into picture from shape and size of the data not data saving/retrieval techniques. yea?

Most definitely not. It has nothing to do with the shape and size of data. Also.. there's not such thing as "distribution" in our context. Only "distributed", from "distributed computing"[1] and it's everything to do about data saving and retrieval :)

[1] https://en.wikipedia.org/wiki/Distributed_computing

NoSQL DBs usually target distributed environments.

So... enter CAP theorem. There's no free lunch. People think we can simply throw away half a century's worth of science because JSON and schemaless are teh awesome derp derp.

Implementation is surely an issue, if you take into account that the mongodb guys had to acquire another company [1] in order to overcome their abysmal write performance. And yet there were people, and benchmarks that were trying to tell us that mongo was faster than RDBMS alternatives. All this circa 2009-2012.

You know what's faster than everything? Writing to /dev/null ;)

Anyways, depending on your use case there might be a NoSQL out there that might fill your needs and it might actually deliver what it claims it can deliver. But it's hard to sift through all this ad-driven, buzzword-ridden informacials that gets thrown around by start-up companies in the DB domain.

Also, DBs are like filesystems; even if the match/science is correct, it needs at least a decade of proven track record before you can say that it works as advertised.

[1] http://www.informationweek.com/software/information-manageme...

Remember, it's just a rule of thumb. Now... tables with 2 32-bit ints as columns are not exactly typical RDBMS data.

Also, data in RDBMS are... well relational :) Meaning, the rows of just one table are not that important. The data are going to be queried and combined with data from other tables. And I know that typical relational data that consist of hundreds of millions of entries in each table is something that most DBs can handle.

Again, rule of thumb :D

The above is good as a rule of thumb indeed.

Another one that I'd add is: - "Are the records in each table in the hundred of millions? Then most probably you'll do fine with an RDBMS".

If you go above that, or you have operations that will extrapolate that number in the billions then you can offload them into whatever non-RDBMS storage you want and do your thing. But that's the thing with RDBMS, you can always move(or offload part of) your data to a non-RDBMS solution afterwards.

But doing the inverse? I wouldn't want to be in that person's shoes ;)

Have you actually used Parse? Obviously not, because you wouldn't dare mention that POC in this discusssion. Hint: search around about experiences.

There's no point discussing with me, because you can't have a coherent debate. Analytics data are not critical neither primary. You really have to reread what I said.

If you have a clue, as you say, and still believe that it's a good idea to store critical data with NoSQL then I don't know what to say.

Obviously you don't care enough that almost every NoSQL solution out there has been found to make false claims about their guarantees. The billions that have been sunk in the blackhole that's called NoSQL in the last decade is unprecedented.

You don't have to change my mind. I have(and still use) both. And I still maintain that people who use NoSQL for 99% of their projects are making the wrong choice.

>In the last 2 decades in the industry as well I've never lost data with MongoDB, Riak or Cassandra but have with Oracle, DB2 and PostgreSQL

Yet every test proves otherwise. Also, use Google to see how people have lost data with MongoDB. Mongo is not considered a serious piece of technology by any scientist or engineer I know. Postgres though is universally considered an engineering marvel.

>Hint: think about the schema problems associated with storing auto generated features from deep learning models.

Hint: The problem you mentioned? Even less than 1%

Calling me ignorant doesn't change reality you know.

Foursquare? For real?

Like what's gonna happen if they have a couple of corrupt data? A minor incovenience at worst?

Is anyone gonna lose millions? Nah. Anyone gonna die? Nah. Anyone gonna get sued? Naaaaaah

Also Facebook uses MySQL for their primary data. Pretty sure it's the same for ebay. Don't know about Adobe, I bet it's the same deal there too.

People get so excited when they hear some big company using X, but they have no clue in what capacity it's used. I can guarantee you that all the data that matters, that need to be consistent and whole are in some kind RDBMS.