Maybe, but the reason it's long is that it's a series of arguments.. supporting points, etc. At least you COULD engage with it if you wanted, unlike so many other pro/con {insert company/platform}.
Oh look, it's a snarky comment on Hacker News dismissing Gruber for writing an article on the topic of Apple, without even attempting to address any of the contents of the article.
Native code is already heavily used in the form of iOS apps, it just isn't part of the web. I am not sure that this distinction is particularly profound considering how reliant the app ecosystem is on the internet. What iOS offers are basic guarantees about the capabilities of the underlying hardware. Web apps can make no such assumptions, regardless of how cleverly they execute the code. So for native client the application will never run fast enough for a significant number of users despite the design goal of increased speed. Unless the app has latency or bandwidth constraints it will always be more reliably faster to do resource intensive work on a server.
I actually did read it. And I'm responding to the idea that "see, you complained, and Google changed it, so your former complaints are now misunderstandings" is really not a valid thesis.
"
The next milestone for Native Client is architecture independence: Portable Native Client (PNaCl) will achieve this by using LLVM bitcode as the basis for the distribution format for Native Client content, translating it to the actual target instruction set before running. "
I actually dislike PNaCL for a different set of reasons, but claiming it was built as an x86 sandbox, and meant to stay that way, is just revisionist history.
If you believed otherwise, it was, in fact, your misunderstanding.
No mention of PNaCL anywhere. Eventually they did change their public messaging away from x86 sandbox and towards PNaCl, though not before causing lots of external confusion and fear. And even then, with the time it took to get PNaCl released, some of the external confusion persisted.
The earlier poster does indeed seem to have misunderstood the history, but it's easy to see where such misunderstanding may come from.
This is not how it was introduced, the blog post was the introduction. We published earlier research papers because we publish papers.
The plan was always the same.
Before this, the project wasn't really real, it was just research.
If you consider this "public messaging", then I guess google should never release research papers or research SDK's without fear of being raked over the coals?
You're right that the first link I posted is a research paper, and that it should be interpreted accordingly. It is interesting though that in the paper, they compare NaCl to other systems, some of which include ISA virtualization, and they specifically say "we made a deliberate choice against virtualization". And this paper is just a small sample of what Google was saying about NaCl in 2009. But you're right, it is still a research project at that point.
However, you apparently missed the second link I posted, which is in fact a blog post and an introduction. NaCl is no longer a research project there. In fact, the post itself specifically describes the difference between research releases and the release it is announcing.
I'm suggesting in 2009, it was random cool research (I actually can't even remember whether it was being funded by chrome back then), not something with a real and true plan to become what it is now.
That really didn't happen until late 2010 or 2011, AFAIK.
I think I could debate this point with you, but I just clicked up the thread to see the context (I only found this subthread because I follow your comments) and can now see why we wouldn't want to perpetuate this subthread.
Your original point, that Portable Nacl is within the original charter of the Nacl project, was valid, even if we can quibble about the timelines. :)
If some code runs orders of magnitude slower it's the same as being incompatible. Yes you might execute an ASM.JS game on older browsers but at 1FPS it's not enjoyable.
Yes, but it seems the blame game plays out differently. If a website won't run because it's demanding a plugin of some kind or a different web browser then the user tends to blame the website; if it runs, painfully slowly, on their browser but quickly on a different model of browser then (s)he tends to blame his/her browser. Really, the way forward is to have things set up so that sites can compile to arch-specific NaCl and PNaCl and "asm.js", and then serve the browser the best one that it will accept.
- "Cool" => "Pseudomature behavior—ranging from minor delinquency to precocious romantic involvement"
- "Lose" => "Early adolescent pseudomature behavior predicted long-term difficulties in close relationships, as well as significant problems with alcohol and substance use, and elevated levels of criminal behavior."
Kudos for the effort and so on, but the thing I can't understand is, who would use these backgrounds, unless they specifically want their site to look like their grandmother's house.
It's 2014. By now we've realized it's counter-productive to stamp your background with pictures and patterns, because they distract from your site's content, and make it harder to read.
Don't have content? The solution isn't funky backgrounds. It's: have content, or don't have a site.
There are entire countries where the modus operandi is finding a position of some power, then finding a way to cheat there so you can get something for yourself. Corruption is a measure of success.
Knowing the loopholes and exploiting them means you're the smart one among a sea of clueless idiots. People get "secret" respect for being corrupted. Former Soviet block countries are one example of this mentality.
There's a reason certain countries can't make quick progress, while others can. Culture is the operating system of the mind, it affects how we perceive the world, how we make decisions, and ultimately where we're dragging the entire society with us.
I never understood why somebody would not find a way to arrange themselves with these types of situations.
There seemed to be three option, either actively start a movement to change the system, or position yourself to profit from the system, or leave the system. Just going around "the system is against me" is one of those victim positions that make yourself feel good but won't make any difference for anyone.
That's easy to say. If you were actually living in that situation, the solution would be less obvious. People have home, roots, family. A situation like that is not black and white. Life is complicated and things are difficult. Be kind.
Who is assuming that "system is against me" victim position you're talking about? I don't see it.
People do what they can in their position. Spontaneous organization leading to system change happens, but it's spontaneous.
Maybe you're imagining some kind of movie montage set to 80s bad disco music, where a guy Decides to Make a Movement, and a movement gets assembled and in the end we get a wide shot with hundreds of thousands of people doing system changy thingies, but reality usually doesn't work this way.
You can't just decide this, especially if you're a ~60 years old network engineer. Deciding to build a life abroad at that age is also quite unlikely.
Missing features weren't Microsoft's problem with Windows Phone. You can't ship from day one with all the features whether you lead or follow.
Waiting until everything is there is a recipe for burning out your team and shipping 4 years later, with zero apps in your app store.
No, the problem is there's simply no compelling reason to own a Windows Phone.
iPhone integrates with Windows just fine. It's popular and feels "safe" because there's safety in numbers, and it has all the apps.
Android is doing well, too.
Microsoft had the chance to ship a phone that integrates better with Windows than any third party phone OS could, but they didn't figure out anything interesting to do with, and just shipped a normal smartphone with a trendy UI on it.
Look at Apple and "Coherence" now. This is the kind of shit Windows Phone should've provided for Windows computers. Instead their roadmap speaks about unifying kernels and what not. Nobody cares about your unified kernels, Microsoft. Ship features that bring visible value to users.
We're carrying cultural inertia from simpler times when people didn't have easy access to the entire world to air their feelings.
It's culturally accepted to share your pain with people you know, and it's culturally accepted not to question or tell people they should keep it to themselves.
The problem is that with the Internet and social media the circle of "people you know" may easily turn out "the entire world".
Quite obviously, our minds are not equipped with the capacity of feeling for everyone's tragedy. If we could truly comprehend the tragedy behind a simple statistic like "thousands die in car accidents every month" it would render us depressed and unable to function.
As we feel more and more like a small village online (with a few billion people in it), the currently established "normal" cultural behavior in case of death will eventually start breaking down.
You are detecting the anomaly of following cultural patterns in a global online community where those patterns are ill-fitting. But most people don't detect it, they just follow the patterns.
Your thinking is not unique, but it's rare. Not many people stop to think and analyze why they're reacting the way they're reacting to your statements. Don't feel bad about the downvotes. We're merely machines running the program (culture) we've been loaded with. We do what the program says is right.
I'm sure the last thing on Eric's mind right now is CSS and especially the implication of a RFC putting the name of his daughter in a technical specification.
It's one of those nerdy endearing gestures that, while made with good intent, only end up causing more pain while simultaneously opening all kinds of strange questions (such as should we build memorials in our technical specifications every time a tragedy hits someone in the community).
Now's a moment to grief, but after long time, a moment comes to move on. Specifications can't "move on". We shouldn't turn them into graveyards where we bury our feelings.
It's always interesting to observe my bad developer practices (such as stuffing JSON in SQL table columns) become flexible "architectural patterns" for building "schema-free, scalable data storage".
Wait until you hear about "fractal storage" where every value in a table is a blob that contains a SQLite database, which in turn has blobs which contain SQLite databases, until it's turtles all the way down.
We actually use a storage format very similar to the FriendFeed schema in Dari. Dari is a open source Java persistence layer with a full query API that stores all it's data in a JSON blob in one table with a few extra tables for indexing the JSON data.
We've used this model for almost five years now with great success. It's simplified rolling out "schema changes" since no tables need to be changed. It's also been optimized to a point where it's extremely fast.
Well I'm saying it tongue in cheek. For a long time I and many others have stuffed JSON in SQL table columns, and I will continue to do so (heck, databases have started supporting JSON as a result).
But every time a developer sees an interesting twist on a piece of technology and goes for it, peers call it a bad practice.
I've been through many cycles like this, and inevitably some time passes, and one day you wake up to see yesterday's bad practices have turned into exciting advancements.
Moral of the story is, ignore the wisdom of the day and go for it, tiger. Stuff that JSON in an SQL table.
I'm not sure which authority gets to pronounce which code practices are good and which ones are bad (the Vatican?), but one thing that I've observed plainly is that this authority can't make up its mind and contradicts itself with regularity. My thoughts are that the whole project of trying to decide for each possible snippet of code whether it is good or bad is foolish and will never succeed. The fact is that everything in programming is a trade-off. Being able to make decisions that don't lead to disaster comes down to experience and wisdom.
What rebelidealist said. In the talk, I try to be pretty clear about what kinds of data are a good case for this kind of storage and what aren't. (In short? Data you only ever retrieve for a single row at a time, and that you never query on. Also, you really need to store it in a separate table that's 1-1 with the main table, or all you've really done is bloated the original table and made things worse.)
My own experience is that there's actually more data than you'd expect that can fit into this model. On the other hand, I am absolutely not pushing this as a panacea: if you don't really know what you're doing, tossing JSON in a RDBMS is probably a really, really bad idea. After all, that's part of the talk -- to discuss when it's a good idea and when it isn't.
Its not always a bad choice. For example, I use it for caching built JSON for requests when a less than reliable API goes down. I can now serve up the cached response for the view without rebuilding it and let the user know we're still awaiting real time data.
Its not storage friendly but it is what I believe to be a valid use case.
If you're working with a 3rd party api and want to store their response, it's waaay simpler to just stuff their response into a json blob, add a couple indexes if needed, and go on with life. (as opposed to making 30 tables to store all the data in a normalized format and writing the sql or configuring the orm to deal with that data)
