The second largest version of Wikipedia is written mostly by one bot - <AUTHOR> https://www.vice.com/en_us/article/4agamm/the-worlds-second-largest-wikipedia-is-written-almost-entirely-by-one-bot <comment><USER2> This endeavor looks largely orthogonal to what the objectives of an online encyclopedia should be. Creating as many stub articles as possible and filling them with "formulaic, generic, and reusable templated sentences with spots for specific information" seems more like a recipe for an automated content farm than for "disseminating the sum of _human_ knowledge."

It would be most interesting to know what the 148 active Cebuano Wikipedia users think of the 5,331,028 articles the bot created, ostensibly for them. Too bad nobody apparently cared to ask.

In particular, since Cebuano speakers are likely to be fluent in Tagalog and/or English as well, they can easily use one of the other Wikipedia editions too. Without the hyperactive bot, the much smaller Cebuano Wikipedia would arguably be more relevant, reflecting topics truly of interest to the community.

While the number of articles is a convenient way of comparing Wikipedia language editions, it only works as such to the extent that the articles are kept to a certain standard. It seems to me that what we are observing here is yet another example of the situation that when a measure becomes a target it ceases to be a good measure.

<comment><USER3> The counterpoint is that automatically-created stub articles serve to encourage community editing. It's much easier to edit an existing article than create a new one from scratch. This is one of the key principles behind the Gene Wiki project[1], which creates stub articles for human genes for this reason:

> Basic articles (called "stubs") were systematically created based on content > extracted from structured databases. These stubs are then edited by the > broader Wikipedia community, while "bots" keep the structured content in > sync with the source databases.

(The "structured content" mentioned is the info box on the right-hand side of a gene article. Nowadays I believe this is populated directly from Wikidata[2].)

Note: I am a member of the lab that runs Gene Wiki, but my work is unrelated.

\---

[1]: [https://www.ncbi.nlm.nih.gov/pmc/articles/PMC5944608/](https://www.ncbi.nlm.nih.gov/pmc/articles/PMC5944608/)

[2]: [https://www.ncbi.nlm.nih.gov/pubmed/26989148](https://www.ncbi.nlm.nih.gov/pubmed/26989148)

<comment> _-___________-_ This seems fine as long as the articles are clearly marked as machine- generated. Machine translation regularly garbles the meaning of text, while producing readable text that has correct sentence structure etc. This is a major problem in an encyclopedia.

<comment><USER4> The subtitle of the article makes it sound like the text in question is machine-translated, but it is created by filling a template with structured data. So long as the template is correct and the data source is accurate, the meaning won't be garbled.

<comment> _-___________-_ I can't really see how the number of translated articles could be as huge as it is using only that approach.

<comment><USER4> Why not? I tried a random article and got one about a park: [https://ceb.wikipedia.org/wiki/Atokad_Park](https://ceb.wikipedia.org/wiki/Atokad_Park) Note that there's no English article about that park that could have served as the source for a machine translation. The article mostly lists a bunch of facts about the location that are easily available in public databases. I don't know how many entries GeoNames.org has, but this park has the number 5063315, so there should be material for quite a lot of articles.

</comment></comment></comment></comment></comment></comment><comment><USER5> I always thought it was a bit bizarre that different language editions of Wikipedia contain different information. It seems the focus should be more on translation than content creation. Maybe that isn't practical with the current structure, but surely the aim should be a definitive knowledge graph rather than a disparate and unevenly duplicated set of articles. Just my two cents – I am sure many have put a lot of thought into how to best tackle this.

<comment><USER6> How do you mean? I'm fine with the fact that the Greek Wikipedia doesn't contain an article about the Boston Tea Party, but I like that it contains an article about the 1821 rebellion. Requiring the information to be the same across languages would mean that either both should be translated, or, if no translator can be found, one should be deleted.

EDIT: Or do you mean contain the same information between different languages of a specific article?

<comment><USER7> I think they mean 2 articles in 2 languages with the same content, or as close as a translator can get. Very difficult to keep updated without automation but that seems like something they want to steer away from until no longer reliant on machine translations.

</comment></comment></comment><comment><USER8> I discovered this in 2018, when comparing lists of languages supported by different software and the number of speakers.

[https://peterburk.github.io/i2018n/#wikipedia](https://peterburk.github.io/i2018n/#wikipedia)

Having machine-translated content is powerful for SEO, but I don't know how practical that is for Cebuano. It would be nice for English to no longer be practically required for people to become computer literate.

<comment><USER9> > It would be nice for English to no longer be practically required for people > to become computer literate.

French here. We are terrible at english in my country.

Still, the fact most information in computing is shared in english is a god send. Sure, you have to learn it, but then:

\- no need to search for it in so many languages

\- no need to produce translations of tutorials/docs/comments in so many languages

\- the community to share and communicated with is huge and diverse

\- english is way more efficient than french, spanish, german or chinese to talk about technical stuff

<comment> seventh-chord Genuinely curious about your last point (don't know much about the topic). Is english intrinsically better at this, or is it because of the presence of jargon? Is it a studied phenomena, or is it something most people feel?

<comment><USER9> English is usually shorter than other latin-based languages. It's longer than ideogram based ones but you don't have to learn 100000 symbols to express yourself in it.

It also has a very simple grammar compared to most languages. Take this sentence:

"I would like not to go to school today"

The french equivalent would be:

"Je voudrais ne pas aller à l'école aujourd'hui."

"would like" is a simple combination of two words, but in french you need to know the precise conjugation of it.

"not" is actually expressed as 2 words with "ne pas", which can be positioned in several ways.

Infinitive, like with "to go", is simple in english: just add "to". In french, each verb is different, like "aller".

Then you got "the" in any circumstances in english, but the "l'", could also be "le, la, or les" depending of the word after it. A;so remember that each word is either feminine or masculine in french, even a stone or the sun.

Then "à" and "école" got an accent. French has many of them, you need to know the right one, where to place it, how to pronunciation it and type it on the keyboard.

Finally, "today" vs "aujourd'hui". I know which one is easier to type in a bug report.

Not to say English doesn't have weird traps, but it's very, very relaxing compared to the rest. And much more efficient.

Also describing a view of the country side with it feels a bit limiting. But I'm not Shakespear :)

<comment><USER10> And then you have Korean.

오늘 학교에 가기 싫다 (I don't want to go to school today)

Hangeul is a syllabary so anyone can read it, just like Latin. It was specifically designed in response to peasants not being able to read Chinese hanzi.

Things like the subject and topic can be and is omitted when it's superfluous. (The above sentence omits the subject and subject particle. There is no topic here). English almost always needs to specify the subject, asides from very casual speech/slang. Korean, like english, doesn't need to specify gender of nouns, and it also doesn't need "a" or "the" markers. The location particle above could be dropped too.

However Korean does have complex honorifics and formality conjugations, which typically get longer the more formal/polite it is. Above we have the plain or dictionary form, which is usually the shortest form as well.

<comment><USER9> How would you express "would like"?

"I don't want to go" and "I would like not to go" express different things.

One is expressing opposition right now, the other one is expressing desire or even a request, potentially while the action is already engaged. The first one is definitive, the second one is wishful thinking or negotiation.

<comment><USER10> I don't see any practical difference other than using more polite, indirect language. The effect of "would like not to" is the same in the end with opposition.

I don't think there's a 1:1 translation of "would like not to". I'd probably say something like "it'd be good if I did / didn't do X". Which is less direct than the equivalent "I do / don't want to do X".

</comment></comment></comment></comment></comment></comment></comment><comment><USER11> I like this because growth and progress of knowledge base, regardless of language or hosting platform, is incremental and cumulative. Wikipedia shows this effectively in the English channel because it happened so quickly. But even the legacy encyclopedias did this through centuries. Whether a bot lays the groundwork from other reference points or dedicated humans do it is sort of immaterial, I think, because the very long run this benefits the people who speak this language.

In an age where languages are dying with their last speakers, Visayan has done much to preserve their diversity -- although not a written/codified language, volunteers give radio broadcasts in the language, books are published in it (here the lack of codification shows by variance in spelling, verb conjugation, and sentence structure), and similar. Thank you to this wikipedian for doing something to preserve a wonderful language (I mention in another comment I am fluent and miss the regular speaking of it).

</comment><comment><USER12> Clicking on random article on [https://ceb.m.wikipedia.org/wiki/Espesyal:Random#/random](https://ceb.m.wikipedia.org/wiki/Espesyal:Random#/random) , looks like every article is that of either a tree, or an animal, or an insect, or a place...

<comment><USER13> And looking at one whole initial article it generated:

[https://ceb.wikipedia.org/w/index.php?title=Klakkabekken_(su...](https://ceb.wikipedia.org/w/index.php?title=Klakkabekken_\(suba_sa_Noruwega,_Odda\)&oldid=14081773)

it describes where the place is and gives the citation as "found in the Geonames.org database".

</comment></comment><comment><USER14> So they mean to tell us "insignificant" facts and articles must be deleted?

<comment><USER15> The German Wikipedia would be twice as big if mods weren't obsessed with some made up criteria of relevance.

<comment><USER16> That sad. In the end, all this would (if not already) make then just go for the English version. I already do this (I'm Brazilian) as the Portuguese version is nowhere near the international (English) version in terms of completeness and being up-to-date.

BTW, do you have a link for their terms on "relevance"?

<comment><USER17> The English version isn't particularly free. I attempted to add a page about a file format that is fairly well used but doesn't have a huge amount of information online about it. The only real source is a zip file from a companies website which contains a pdf with the file spec and some example programs. Unfortunately the editors decided that due to the lack of referencable sources, they would rather no article exist at all.

<comment><USER14> This bullshit policy drives me mad. I will start donating regularly once it's cancelled. Not sooner, nor later.

<comment><USER17> I understand it for some cases where the mods just need to stop people making up random crap on topics that don't exist or can't be verified. But in this case a single reference is more than enough to write the whole page because the spec is literally the only source of truth on the topic.

Unfortunately I think the mods may be too passionate about "protecting the integrity of wikipedia" that they let legitimate content be deleted. It also doesn't help that the wikipedia UI for disputes and edits is really confusing and I had a hard time trying to work out what was going on or how I communicate to this moderator. The whole system is designed for power users only.

<comment><USER18> It's important to note that there are not only "the mods", but two opposing factions in Wikipedia: the Deletionists and the Inclusionists. [1]

I too agree that we don't need articles on someone's cat, but I've had articles deleted as not notable on indie web comics and indie role-playing games with hundreds or thousands of readers or copies sold.

I thought that the fact that the RPG was published and publicly available, and was being discussed in RPG forums would make it notable enough, especially when it was mentioned as an inspiration for rules in more traditional RPGs. But since they hadn't been mentioned in any published articles they were deleted and there was no real way for me to fight it. I had added stuff like the list of contributors, publishing year, and overview of the rules and setting, with no personal discussion of the game.

The result was that I stopped trying to improve Wikipedia, because I don't have the time or interest to fight people with an infinite amount of time that deletes my additions. My main contribution to Wikipedia wouldn't have been on the articles on Barack Obama or World War II anyway, as they already have people who are experts that add information. I could have brought information on my specialized topics of interest, but realized that they would all seem non-notable to someone who's not interested in the same thing and would be deleted.

[1] [https://en.wikipedia.org/wiki/Deletionism_and_inclusionism_i...](https://en.wikipedia.org/wiki/Deletionism_and_inclusionism_in_Wikipedia)

</comment></comment></comment></comment></comment></comment></comment><comment><USER19> Slightly pedantic but the largest "Wikipedia" (depending on how you define it) is [http://wikidata.org/](http://wikidata.org/) and it's also primarily written by bots.

<comment><USER20> That's a wiki, not a Wikipedia.

<comment><USER19> but both are wikimedia projects</comment></comment></comment>


Show HN: An Experimental Parenting Initiative - <AUTHOR> https://handsonparent.com/ <comment><AUTHOR> Hey all, I started this little initiative a few months ago where a few parents wanted to actively take part in preparing the children for the times to come, in hopefully a balanced way.

We have created this blog in the hope that our learnings and failings might help other parents. We started off with this document [https://handsonparent.com/2019/04/01/what-is-hands-on- parent...](https://handsonparent.com/2019/04/01/what-is-hands-on-parenting/) that kinda shows our core aims.

I would be extremely happy to receive any feedback on the content and the initiative as a whole.</comment>


Buffett's Alpha (2018) [pdf] - <AUTHOR> http://docs.lhpedersen.com/BuffettsAlpha.pdf <comment><USER2> From what I have seen, only certain quant funds like Renaissance Technologies and TGS Management have actually truly managed to beat the market in a consistent non-random manner.

And they do exactly what you'd expect someone who has a money making machine to do- shut up and at some point kick out your external investors.

<comment><USER3> Quant trading strategy like Medallion Fund uses don't scale. That's why Warren Buffet has more personal wealth than Medallion Fund has AUM.

Outside finance, but similar business is sports betting syndicates. They can make 30-70% yearly return with low volatility. If you bet in 100 events per week and the expected return from each bet is just 0.5% (after expenses) you make consistent 30% return with very low volatility. If you make 1% per week you get almost 70%.

That's great return for the investment but the size of investment is typically limited to tens of millions. Brokers don't like it and close accounts when they notice them. There is increasing amount of work involved when the amount of money increases.

<comment><USER4> Do you have more information about this? I thought "the bank always wins" (or the broker in this case).

<comment><USER5> Jim Simons

[https://news.ycombinator.com/item?id=21423845](https://news.ycombinator.com/item?id=21423845)

Maybe Ed Thorp too:

[https://en.m.wikipedia.org/wiki/Edward_O._Thorp](https://en.m.wikipedia.org/wiki/Edward_O._Thorp)

<comment><USER6> And barely a drop about TGS on the clearnet (aside from some paywalled BBG articles). They are basically the continuation of Ed Thorps business Princeton Newport Partners.

<comment><USER2> TGS is extremely secretive

[https://www.google.com/amp/s/www.cnbc.com/amp/2014/05/09/mys...](https://www.google.com/amp/s/www.cnbc.com/amp/2014/05/09/mystery-13-billion- philanthropists-revealed.html)

</comment></comment></comment></comment></comment></comment><comment><USER7> Actual date: 2013. And, now submitted 7 times in the past year: [https://news.ycombinator.com/from?site=lhpedersen.com](https://news.ycombinator.com/from?site=lhpedersen.com) .

</comment><comment><USER8> >However, we find that the alpha becomes insignificant when controlling for exposures to Betting-Against-Beta and Quality-Minus-Junk factors.

It's always easy to see how you could have made money with hindsight. I bet if you implemented the Betting-Against-Beta and Quality-Minus-Junk strategies now you wouldn't do nearly so well.

</comment><comment><USER9> I think, for each equation in your explanation of what you've done you should have to include a picture to compensate.</comment>


HuRandom: A project about 'random' numbers - <AUTHOR> http://hurandom.elijahcaine.me/

<comment><AUTHOR> HuRandom crowd sources the collection of human generated random numbers to study trends in how people perceive 'random' data. Contribute for science!</comment>


Ask HN: Do you see any value in a Persistence as a Service platform? - <AUTHOR> I am hoping to have a prototype platform soon. It is to simplify relational data access and make persistence a backing service for microservices and serverless applications. You will specify persistence services with SQL and JSON only using a WebIDE and run them as managed services. I am uncertain how useful this is and would like to hear from you. If interested, slight more info is here: https://github.com/bklogic/backlogic-persistence. Thanks in advance. <comment><USER2> Hmm... Hard to say. I think you may have trouble differentiating your product with this description. When I hear "persistence as a service" my first thought is "I can just use RDS, or maybe something like Firebase. If those aren't suitable, how hard is it to spin up my own instance of (Mongo|Postgres|FoundationDB|ExistDB|DB2|Oracle|SQL Server|CouchDB|etc) in the cloud?"

Of course the fact that RDS, Firebase, etc. exist suggests there is a need for persistence services in the cloud. I'd just be curious to know how your thing is different/better than the existing alternatives?

<comment><AUTHOR> Thanks for your comments. This is actually a externalized layer between RDS and application. It hosts the persistence logic normally implemented by ORM. However, this platform attempts to provide a simpler method for creating the logic. For example, to create a query service, you would just specify the input and output for the service with JSON and then a SELECT statement for the query. The other two services you may create include a SQL command service and a aggregate CRUD service, all with help of a GUI Service Builder. With your comments, I see the need to carefully phrease my product to avoid confusing. Thanks.</comment></comment>


Ask HN: What do you use for pair-programming interviews? - <AUTHOR> <comment><USER2> [https://qualified.io](https://qualified.io)</comment>


Hands on with the 2D to 3D convertor emulator - <AUTHOR> http://arstechnica.com/gaming/2016/06/hands-on-with-the-emulator-that-adds-depth-to-old-2d-nes-games/ <comment><AUTHOR> Hands-on with the emulator that adds depth to old 2D NES games</comment>


Four cents to deanonymize: Companies reverse hashed email addresses - <AUTHOR> https://freedom-to-tinker.com/2018/04/09/four-cents-to-deanonymize-companies-reverse-hashed-email-addresses/ <comment><USER2> Nothing a little SALT cant fix. If you salt the password with a secret key, then it is no longer a guessable hashed email. The SALT/key can then be passed up the chain or authority doubling as a chain of custody. But let's be real, few programmers will take that much care to protect ones email.</comment>


Microsoft Is Ready for a World Beyond Windows - <AUTHOR> https://www.theverge.com/2018/3/30/17179328/microsoft-windows-reorganization-future-2018 <comment><USER2> They should then release the XP 2003 API calls so ReactOS can take over when or if Microsoft abandons Windows</comment>


Google Glass Team: 'Wearable Computing Will Be the Norm' - <AUTHOR> http://www.wired.com/gadgetlab/2012/06/clear-glass-leaders-googles-wearable-computing-breakthrough-explain-it-all-for-you/

<comment><USER2> _Some people who have interacted with Glass testers feel that sometimes people seem to temporarily drop out of a conversation to process something they see on the display. How does Glass avoid being something that removes us from our physical environment?_

My feeling is that this effect might fade away as people become more used to the device. Anyone who wears glasses can tell you that the first time you put them on, the frames are very distracting in your peripheral vision. You become accustomed to them rapidly, however-- within days, the frames are invisible, and you retain this even when you take them off for a while.

A similar phenomenon takes place when driving. Every now and then you realize that you weren't watching the road at all, just driving along automatically with your peripheral vision. And the haptic compass experiments have demonstrated people have the ability to gain an unconscious sense of location from external stimulus.

Obviously something popping up in focus is always going to be distracting, but with a notification icon in the corner of your eye, it's entirely possible that one would grow used to it and stop consciously noticing its appearance-- you'd simply have a somewhat-unconscious "email sense".

And there's no reason that should distract one from what they're doing; when the mail comes to my door, I don't stop whatever I'm doing and go read it. I make a mental note to check the mail when I get a chance, and continue the conversation.

I'm pretty excited about this technology.

<comment><USER3> "My feeling is that this effect might fade away as people become more used to the device."

The effect of removal from the environment will not fade, but the social ramifications for the user will. People are less pissy now when someone stops to check their phone during a conversation, but that's more due to the expectations of those around them rather than our expanded ability to functionally multitask.

<comment><USER2> I feel like you didn't really read my post, since I was making a case that the "effect of removal from the environment" _will_ fade that you didn't address... That aside, I think you're making a good point.

Part of the promise of the information age is general cognizance of the fact that we live in an incomprehensibly vast and complex universe, and that we are only able to perceive the most infinitesimal mote of it during our lives. With the judicious application of technology, we can expand our perceptions many times by accumulating information from different parts of physical space. For thousands of years, it was possible more or less to pretend that there was nothing else in the universe outside this room, and no one else alive but your family; thanks to the internet, that is purely impossible today.

It should not be surprising that this frightens some people.

Technophobes frequently protest that assisted communication can't have the value of face-to-face speech, which is frankly complete horseshit. Most of the in-person conversations that most people have most of the time are more banal and purposeless as the front page of Reddit (or 4chan, depending on your peer group). What is important is the relationships that we have with other people, and I've seen nothing in my experience or the literature to imply that relationships are intrinsically less meaningful because they are not communicated in person.

This sentiment is a form of forceful control exerted by those who have no other reason to command attention but proximity. This is also crap; attention is a product of interest and respect. If I am not interested by what you are saying, you will not maintain my full attention for long; and if you demand my full attention for no other reason than that you happen to be the human being closest to me in physical space, neither will you my respect.

<comment><USER3> cmon its not complete horseshit, getting to know somebody not just through their written or spoken idea but their facial expressions, their scent, their subtle body language is all meaningfully a part of our cognitive experience. Just because those things haven't necessarily been incorporated into cutting edge technology does not make them less relevant. We're all very impressed with ourselves for making cool gizmos that do wonderful things, but the backslapping and focus we have on our own achievements doesn't lessen the importance of the parts of our experience that nobody has even begun to effectively tackle. There are parts of human interaction that are not replaced by technology, at least not in its presence or near-future form. Period.

I did read your post, I disagree that the tune out will ever end, its just how it's read by others will culturally shift. you're still gonna be withdrawing your mental presence from the space, an externally triggered space-out.

</comment></comment></comment></comment><comment><USER4> At the risk of sounding silly a few years from now, I'll draw connection to when personal computers were first coming out. It was hard to predict all the uses we have today, and spreadsheets were thought to be one of the killer apps. Similarly, photos and sharing is the obvious killer app with Glass right now, but that's because it's very hard to see that far ahead. I can't wait to see what masses of developers will come up with once it's out for a while.

Further in the future, the device will likely shrink to, or work with a contact lens. At this point, this is not even a question of science, but of engineering [1].

[1] [http://wireless.ee.washington.edu/papers/Lingley_JMMNov2011....](http://wireless.ee.washington.edu/papers/Lingley_JMMNov2011.pdf)

</comment><comment><USER5> Is it just me or is the likelihood of this taking off a little lower than the Segway revolutionizing transport worldwide?

<comment><USER6> Segways would need parking / secure storage, or lots more upper body strength on the average person to get them up stairs. Costly physical barriers to widespread use.

Something like this pretty much just needs something to charge from. Like your computer while you work, and the wall while you sleep, from a USB port perhaps (which you already have).

Not making any claims as to which are more useful / applicable to more people. Just that there are major physical barriers to anything that requires even a _pocket_ , much less infrastructure. A small wearable computer just requires somewhere to sit when you're not using it.

<comment><USER5> I can imagine people wearing headsets like that all the time would cause innumerable problems.

They'll be like bluetooth headsets. Reserved for a very _specific_ subset of the population.

<comment><USER7> You're assuming that you'll even be able to tell who's wearing one rather than regular glasses. Look at the change in form factors of MP3 players and phones over the past 10 years, and then look at where they're _starting_ from with these. No reason they couldn't be nearly invisible by the time they hit widespread use.

<comment><USER5> You'll be able to spot those people because they're always walking into things or muttering voice commands to nobody in particular.

Don't tell me you can't spot someone with a portable music player from a hundred feet away. If anything the visibility of those has increased as the popularity of over-sized headphones has grown.

<comment><USER7> Can you spot someone with a hearing aid from ten feet away? Not these days.

</comment></comment></comment></comment></comment></comment><comment><USER8> Google Glass can be divided into (at least) two distinct parts. The camera and the display. The camera is what Google is pitching very heavily right now. I'd guess they're doing that because it's something people can relate to... taking pictures from your perspective, taking them without putting some device between you and your subject. The tiny camera that takes pictures from your eye level is a big enough draw to get early users interested. (The killer app is "real-life" DVR... why should you have to stick your camera phone in front of your face to take a picture or record a video... how many times have you thought "damn... if I just would have had my phone ready I could have grabbed an awesome shot").

The display is harder to understand. What information do you need in front of your eyes right now that actually helps you? Today you might check Yelp for a restaurant review or Google Maps for directions, but you rarely ever keep your phone in front of your face while you walk through New York... it's a reference, not a constant aide. It's a cool idea but most people (even some of the geeky ones who visit Hacker News) don't see the value.

I think the big vision here is that you'll have a camera that consumes the world around you and a system that can process what the camera is seeing, and give you real useful information about the world around you immediately. You walk into the office and the system tells you that you're looking at "Sarah" and you have a meeting with her at 3pm, or that the menu item you're looking at has 615 calories and most people who order it love it, or that the product you're about to buy is $50 cheaper at an online store and can be shipped to you in 2 days. Glass doesn't offer any of this right now... but it will some day. I want one and if I'd attended Google I/O I'd have spent the $1500 for the early prototype.

<comment><USER9> I don't think this device alone would make this big difference. we already have phone that are able(especially with the cloud) to do augmented reality. In many use cases we don't need this immediate response. we can "take the time" and get our smartphone.

We point our phone at that product, or at our lunch, or at the home diy project we need to do, or at some hobby we're doing, or at the car repair we're doing. we don't need glass for that.

</comment></comment><comment><USER10> Are we supposed to _want_ this? As if it wasn't already hard enough to talk to people who are constantly whipping out their smartphones.

</comment><comment><USER11> Control input will make or break this thing. I don't think a single button and touchpad will cut it for general computing.

They're riding the wave of hope that voice controls have now, maybe I'm naive but it's going to have to improve by miles for anything beyond novelty use.

I could see this focusing on a tighter use case, like content aware eye mounted cameras with social features, and why not two of them for stereoscopic?

<comment><USER12> Touching it at all is likely a deal-breaker. People would likely prefer using a 'remote' on their phone to issue commands, rather than using an indirect pointing/clicking device on their temple.

Mobile is primarily different from Desktop in that the little annoyances are too much for the form factor and use cases. And indirect pointing and clicking just doesn't cut it in mobile.

Wearable will only be more extreme this regard.

<comment><USER13> Or a wristwatch shaped device.

</comment></comment></comment><comment><USER14> I cannot in my wildest stretch of imagination see myself ever buying something like this.

<comment><USER15> Just wait

</comment></comment><comment><USER16> "So we decided that having the technology out of the way is much, much more compelling than immersive AR, at least at this time."

I'm not really convinced by this. "Out of the way" means you have to switch focus every time you want to see your information, and then switch back afterwards. To me, this seems even more distracting, albeit less prone to clutter.

</comment><comment><USER17> I'd suggest they design the device as something that clips on to spectacles. I don't see why anyone would wear this thing if they weren't going to wear spectacles (why have the whole stupid frame?) and it's not going to work for spectacle wearers (which is a lot of us).

As for the comment about making something that doesn't come between the user and the physical world -- how about not using this device?

I think it's an intriguing concept, but right now it's a solution looking for a problem. Building software this way is relatively cheap (Google Wave...) but hardware?

It makes me think that an audio-focused UI that allowed commands via throat mike might be a good way to go.

<comment><USER18> I agree that wearers of prescription glasses would make an excellent target group: We're already comfortable with the mechanics and aesthetics of wearing a device in our face, and many of us are also used to spending $$$ for eyewear.

<comment><USER19> I would totally do this.

</comment></comment></comment><comment><USER20> Imagine a world where OLED screens can be worn or even tatooed to the skin, powered by kinetic motion?

It's a brave new world, aye!

<comment><USER21> Or even powered by excess blood glucose?...

<comment><USER11> Are you implying I'm producing more than absolutely necessary? How dare you.

<comment><USER22> Probably referring to this[1], though I'm hoping they come up with a way for me to power my house. Finally, a reason to pull out the Nutter Butters.

1\. [http://www.extremetech.com/extreme/130923-mit-creates- glucos...](http://www.extremetech.com/extreme/130923-mit-creates-glucose-fuel- cell-to-power-implanted-brain-computer-interfaces)

</comment></comment></comment></comment><comment><USER23> ... like video calls!</comment>


How to Use User Mode Linux - <AUTHOR> https://christine.website/blog/howto-usermode-linux-2019-07-07 <comment><USER2> UML has been around for a very, very long time. I remember using it back in undergrad for one of my courses, but now I forget which one.

It's got great documentation. See the kernel.org documentation here: [https://www.kernel.org/doc/Documentation/virtual/uml/UserMod...](https://www.kernel.org/doc/Documentation/virtual/uml/UserModeLinux- HOWTO.txt) and a write up from the creator Jeff Dike (which includes a lot of technical detail on the inner workings) here: [https://lwn.net/2001/features/OLS/pdf/pdf/uml.pdf](https://lwn.net/2001/features/OLS/pdf/pdf/uml.pdf) (from 2001!)

slirp is the only _purely usermode_ way to do networking, but UML also supports TUN/TAP for something a little more sane. UML does a bunch of pretty crazy things in order to work, including a dedicated thread whose job it is to ptrace every other process for syscall and signal emulation (and, as a bonus, it even ptraces external debuggers to make them think they've successfully ptraced a process that's already being traced!), and a full emulation of physical/virtual memory translation with paging (done by giving every virtual process under UML its own virtual address space).

All in all, a super impressive project, and definitely one worth trying out.

<comment><USER3> I've recently been using proot [1] as a way to have a fully controlled rootfs for jobs on a HPC cluster/grid service where I am a very regular unprivileged user.

Is it theoretically possible I could run an entire linux kernel instead with this? Is there any setup on the host system that is required which needs administrative privileges?

[1] [https://proot-me.github.io/](https://proot-me.github.io/)

<comment><USER4> The HPC usage scenario is exactly the reason why I played with UML a few years ago. Many HPC clusters nowadays completely lock down the network and only allow in/outbound SSH connections to whitelisted IP networks. On the other hand, users are only given an unpriviledged account. Typically, users set up proxies on a per-application level (i.e. for git, svn, to sync their codes with the outer world). I found this very frustrating and wanted to use any usual Linux command line tools. My idea was a UML based virtual machine (ie. running a Linux distribution within UML) and have it connected to the outer world by tunneling a single slirp and VDE connection. VDE is quite amazing because it marries unix pipes with ethernet-level networking. It even allows to run ethernet switches as processes and all that. My codes based on [https://github.com/jpetazzo/sekexe](https://github.com/jpetazzo/sekexe)

Turned out: It basically worked, but it was a bit painful to setup and to manage.

<comment><USER5> I'd have thought it would be relatively unusual not to be able to use HTTP into a cluster login node, but I'm puzzled why you can't "sync code" with ssh otherwise. If you're prevented from doing things you need to work, it sounds like an institutional politics problem; subverting controls is likely to cause more friction as well as presumably wasting resources due to inefficiency.

</comment></comment></comment></comment><comment><USER6> Many many years ago, when I was working at a large 3-letter-starting-with-S Unix company (no, not the graphics guys, nor the suing-Linux-for-Microsoft guys), we were planning a Linux compatibility layer... At the time, there were a couple of options out there - lxrun and uml. Anyone remember lxrun? I tested them both and did a little write-up, basically saying that neither of them ran reliably or fast enough to be worth adopting

What we decided was to go with option 3 - we implemented a Linux system call interface within our own kernel to give us 'native' support. This, of course, is exactly what the first version of WSL did, many years later. Plus ça change...

<comment><USER7> >at a large 3-letter-starting-with-S Unix company (no, not the graphics guys, nor the suing-Linux-for-Microsoft guys)

Is it Sun? Why use more than 20 words to (probably) mean "for Sun"?

<comment><USER8> Presumably they think this is a defense that will hold up in court as plausible deniability if they are ever sued for defamation relating to this comment.

<comment><USER6> You guys are weird. It was just a bit of wordplay :D

<comment><USER8> I didn't really have an issue with what you wrote. It made me realize there are several three-letter, starts-with-S, Unix companies.

</comment></comment></comment></comment></comment><comment><USER9> Brings back memories. My first VPS back in 2003 used UML and it worked great. You could also run it inside Windows as well. Could even get GUI apps running by running Xming on your Windows desktop using CoLinux ([http://www.colinux.org/?section=screenshots](http://www.colinux.org/?section=screenshots)).

<comment><USER10> Colinux was freaking great, I could run an OpenSSH server on port 22 and sometimes ending up on a Linux box, sometimes on a Windows box. Weird.

</comment></comment><comment><USER11> I have often thought back to how great UML was. I had filed it under "distant history" when I thought about it last week...

Back in 2003 or 2004, I threw together a "virtual hosting" platform using UML. It had a web form accepting payment, and a few minutes later you'd have a fully running virtual machine. I put this together in a couple weeks leading up to PyCon, where we launched it. But we didn't really have the business savvy to take it anywhere, we never had more than a few hundred VMs.

We eventually moved to other technologies: VMWare, Xen, Proxmox (KVM). But UML was my favorite. (Xen was my least favorite :-)

</comment><comment><USER12> The next logical thing to do for more fun is to run User Mode Linux under the Windows Subsystem for Linux.

After that, it would make sense to try WINE.

<comment><USER13> A Windows app running on WINE inside UML inside WSL of a Win10 which is itself a VM running on e.g. macOS would be funny to see.

<comment><USER14> Does WSL support ptrace now? UML can't run without it.

</comment></comment></comment><comment><USER3> [https://lwn.net/2001/features/OLS/pdf/pdf/uml.pdf](https://lwn.net/2001/features/OLS/pdf/pdf/uml.pdf)

In 2001 this mentions SMP support is possible. First thing tomorrow I need to check if it was ever implemented. Perhaps it's late and I'm tired but somehow this seems to be much better than containers for a number of problems, or maybe the performance hit is too much.

</comment><comment><USER15> Off topic, but here it goes: I really like the styling of this website. I shouldn't like it, because I don't like non-proportional fonts being used for prose, but it works great in this case.

Also loads super fast, which is an exception these days.

<comment><USER16> I like it as well. It looks like one of those generated static sites from hugo or haunt. I've been seeing it more often lately and I think it's a good trend.

<comment><AUTHOR> My site isn't actually a static site. The code is in [https://github.com/Xe/site](https://github.com/Xe/site)

</comment></comment></comment><comment><USER17> I had no idea this was possible. Excellent article - thank you for opening my eyes to yet another insanely cool aspect of Linux.

</comment><comment><USER10> weberlars/diuid [https://github.com/weber- software/diuid](https://github.com/weber-software/diuid) runs a UML in a docker container, which then runs a Docker daemon of a different version inside. Clever.

</comment><comment><USER18> It would be nice to combine UML with an encrypted root filesystem so a nosy admin on a VPS will have a harder time seeing what you are doing on your VPS. Still I wonder what the performance will be like. Is the entire UML process running single threaded on a single CPU core?

<comment><AUTHOR> Each process in the guest has its own host thread, but yeah the way I have it set up there's only one logical "CPU core" being exposed to the guest.

</comment></comment><comment><USER19> Great work!

I am trying to run this on the latest Ubuntu but getting the below error:

root@kit:~/uml/furry-happiness# docker run --rm -it xena/docker-uml [WARN tini (7)] Tini is not running as PID 1 and isn't registered as a child subreaper. Zombie processes will not be re-parented to Tini, so zombie reaping won't work. To fix the problem, use the -s option or set the environment variable TINI_SUBREAPER to register Tini as a child subreaper, or run Tini as PID 1. Core dump limits : soft - NONE hard - NONE Checking that ptrace can change system call numbers...ptrace: Operation not permitted check_ptrace : expected SIGSTOP, got status = 9

<comment><AUTHOR> What host OS do you run? I got this working on both Ubuntu and Alpine.

<comment><USER19> I am running this on ubuntu 18.04 :(

</comment></comment></comment><comment><USER20> When I tried User Mode Linux I found that there was very little in the way of ready-made, up to date tooling.

Very little "just worked".

I think there's huge potential there, however, as an architectural building block, just like containers are.

<comment><AUTHOR> It's the kind of stuff that drives you insane a bit. You have to hack together things from software last released in 2006. You have to dig through kernel source code to really understand what is going on in the user mode Linux drivers.

</comment></comment><comment><USER21> The article states that processes in User Mode Linux are completely isolated from the host, and cannot be seen.

Could someone clarify this for me - there must be _some_ way of pulling data from UML back into the host system?

<comment><USER2> Actually, very much on the contrary, the processes running inside UML are completely visible as separate threads within the UML process, and you can go poking their `proc` files at-will. Also, UML uses a read/write disk image as the rootfs, so any writes to the filesystem will be persisted in the disk image.

<comment><USER3> > processes running inside UML are completely visible as separate threads > within the UML process

Does this mean the UML system can utilize many cores well and SMP was eventually implied?

</comment></comment></comment><comment><USER22> Very nice. Now I'm tempted to try and run X11 and firefox in UML somehow.

</comment><comment><USER7> How does this compare to other methods of isolation / running untrusted code? What are the pros and cons?

<comment><USER23> [https://www.linode.com/](https://www.linode.com/) used to run off UML, though they switched quite a number of years ago. It might be worth hunting out their documentation and/or forum archives from around the time of the transition. I recall a lot of detailed discussion (useful discussion too: not just people bashing the technology they don't prefer).

I used to run it myself, way back when. For isolation, it is going to be better than a container or jail, but not as good as a full VM, though I was using it for testing personal stuff so wasn't really concerned with isolation from a security point of view. One key con is that it can perform pretty badly in some respects, particularly for loads that ned to talk to the kernel much at all, including processes that perform much IO. It "felt" less cumbersome than full VMs (IIRC I was playing with a mix of VirtualBox and VMWare' Player & Server for that sort of thing at the time), in terms of my automation and to some extent in terms of host resource use (though I didn't test that with any scientific rigour, and if I did any good tests back then the results would not be relevant today anyway as they were pre VT-x and other CPU support which UML can't use but a modern hypervisor can and will).</comment></comment>


Meteor hits 1.0 - <AUTHOR> https://www.meteor.com/ <comment><USER2> I'm still a bit unclear on what the target market for Meteor is. Is this just for small to medium sized projects, or is it intended to be used for large- scale projects as well?

Since it seems like everyone wants to think of themselves as doing something huge, I'm sure the answer can't be 'no' to the second question — but I don't see any examples of significant projects being built on the platform. Actually, with that in mind, what happened to the gallery of projects built on top of Meteor? Perhaps I'm missing it.

All that being said, congratulations on reaching 1.0. There's clearly a lot of great energy and thought that went in to the project.

edit: The videos on the site weren't obvious to me at first, but after finding them I think this one is a good counterpoint: [https://www.youtube.com/watch?v=QzhtQzAX_6k](https://www.youtube.com/watch?v=QzhtQzAX_6k)

<comment><USER3> It's definitely a win for hackathons and getting a MVP out there that needs real time features. I can't speak much for large scale projects since I haven't had the fortune of reaching that scale yet with meteor, but I'd imagine it will be ideal for that eventually simply by extrapolating the current growth and improvement trends of the framework.

<comment><USER4> At last months devshop in SF a speaker discussed straining the system and reaching the limits of Meteor with just hundreds of simultaneous connections:

[https://www.youtube.com/watch?v=cJbGNpmE7f0&t=8m30s](https://www.youtube.com/watch?v=cJbGNpmE7f0&t=8m30s)

Hundreds isn't really exactly "webscale", but I'm sure they'll iron it out, or it could have just been the application that was at fault. It's one data point however on how meteor scales.

<comment><USER5> [I work at Meteor and contributed to the MongoDB realtime driver]

Scaling low-latency data synchronization is a challenge for scalability for sure! We are gradually building better and better drivers with persistence to MongoDB.

The scalability can vary greatly depending on your application's data schema, usage patterns and amount of writes.

If you watch the mentioned talk carefully, the speaker describes a collaboration tool with log replay with a lot of actions and running from a single box.

<comment><USER6> The "running from a single box" at the end seems like it could be the most important part of the equation. Would you agree? Or rather, would that be the recommended place to start optimizing if your app runs into scaling problems?

<comment><USER5> Here is a very fine blog posts series on scaling Meteor horizontally, please consider looking at it: [https://meteorhacks.com/pro- meteor/](https://meteorhacks.com/pro-meteor/)

<comment><USER6> Interesting, thanks. In that first blog post it mentions that Meteor serves static files. Is that a requirement?

edit: posted too soon they talk about it here [https://meteorhacks.com/does- meteor-scale.html](https://meteorhacks.com/does-meteor-scale.html)

<comment><USER7> And you can use cloudflare or some other CDN very easily. See: [https://meteorhacks.com/cloudflare-meets- meteor.html](https://meteorhacks.com/cloudflare-meets-meteor.html)

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER8> Congratulations on 1.0 but these kinds of buzzwordy lines

        Accomplish in 10 lines what would otherwise take 1000,
        thanks to a reactive programming model that extends all
        the way from the database to the user's screen.

Really bother me.

Show me where you eliminated 1000 lines of code and how it was beneficial. Each line of code, to me, is placed with purpose and intent.

Are you eliminating thousands of lines of boilerplate? Or are you making best guess assumptions that fit the common need, and we still end up with those 1000 lines for something truly custom?

<comment><USER9> (Disclaimer: I work at Meteor) That box is referring to the data syncing, event handling, and view rendering code that you don't have to write when you use Meteor, compared to some of the previous generation frameworks.

If you put together the right list of cutting-edge components like React, Firebase, Bootstrap, and some build tools, you might get a similar improvement in code simplicity. Our goal at Meteor is to give you the same benefits without making you write code to plumb between several different frameworks.

<comment><USER10> I'm doing a rebuild of a personal project over the holidays and I spent some time looking into binding together React, Airbnb's Rendr, and JSX through Browserify and Grunt. It's possible, but it's a nightmare. Meteor definitely succeeds and just delivering that.

(Not that that is the only requirement you might have.)

<comment><USER11> I'm using React. My server-side rendering is essentially `React.renderComponentToString(App(data))`. The only difference between how I invoke my app on the server vs on the client is that instead of `React.renderComponent` I use `React.renderComponentToString`. On the client, React just uses the pre-rendered HTML and binds itself to that without re- rendering a single DOM node.

All my scripts are in `package.json`. I don't use Grunt or Gulp. If I want to re-bundle my client, I invoke a script that essentially does `browserify -g uglifyify lib/browser.js > dist/main.min.js`. My JSX build script and the bundler script are automatically invoked by a watcher.

This[0] is my entire build script and the only reason it's verbose is because I like to be able to execute each task separately if I want to.

The only problem with React is that it is _only_ a view library. It only does components. The blessed solution is a Flux-like architecture as implemented by Fluxxor or Reflux, but you can integrate React into nearly anything you already have. I like the immutable/unidirectional approach React and Flux share and ended up writing my own library[1] because there were things I didn't like about the existing Flux implementations, but you don't have to do that.

I have to admit that Flux has a steep learning curve. And if you've never dealt with immutability before it can really melt your brain. But I don't see how Meteor is any easier to pick up, especially considering that it comes with its own entirely separate ecosystem (the only non-node library I use in my React app is an XHR-wrapper that replaces `request` on the client).

[0]: [https://gist.github.com/pluma/61a1639906e188be8423](https://gist.github.com/pluma/61a1639906e188be8423)

[1]: [https://github.com/foss-haas/flox](https://github.com/foss-haas/flox)

<comment><USER12> I agree with you that it probably is not easy to pick up, but I have to admit, there is significantly less to deal with. Meteor is the fullstack, and it even has sockets built into it. You definitely have to buy into one ecosystem, and that's convenient because you don't have to know a serverside ecosystem (e.g. Rails) and a frontend ecosystem (e.g. Angular, React, and Ember).

<comment><USER11> Sure, but my current ecosystem is npm. For browser-specific substitutes to node-specific code I simply use browserify. If I decide React is boring, I can switch to an entirely different front-end without changing anything else. For stuff that isn't on npm I have to work with bower or something else, but that (i.e. ecosystem-external dependencies) is a problem in any application, not specific to npm.

With Meteor, you're developing Meteor apps. Sure, you can put a different front-end in it or replace its server-side with an API compatible equivalent, but that's like saying you can use Django without its template system or ORM (if you don't know anything about Django: you can, but Django's built-ins provide a lot of synergy that you can only get from tight coupling).

</comment></comment></comment></comment></comment></comment><comment><USER10> There's a lot to like about Meteor. Just compare setting up some kind of "dream team" of JavaScript: Rendr + React + Grunt + JSX = OMG WHERE DID MY FRIDAY NIGHT GO.

Meter out of the box "just works," but it only works with Mongo for now, and it only works if you are all-in with the platform — on both the client and the server side. Those are two pretty big bets to make.

I would say Meteor is ideal for learning, except that it's important to learn what the request-response lifecycle is all about, and I think it can be detrimental when a "magical" framework does so much for you.

And one thing I just can't get over -- page loads in Meteor.com feel super fast. Until you realize it actually downloaded the contents (not the unseen images, of course) of the entire website! DPP is doing some interesting things, but some of Meteor is some nice magic tricks that we've seen before. 600kb+ of JS on page load is certainly an interesting concept.

Huge amount of work by a talented team. A super nice community. As for the framework itself, give it some time, let it grow, but most importantly, understand objectively its strengths and risks. It has both!

<comment><USER11> First of all, why is JSX in that list? It's essentially an ES6 transpiler with syntactic sugar for nested function calls. If you mean the additional build step it requires, that doesn't really make sense either: you should be bundling and minifying your client assets already and JSX is just another (fully transparent) link in the build chain.

Secondly, why Rendr? Rendr was built for Backbone. The most recent info I can find that suggests using Rendr with React is over a year old. React can be rendered on the server just fine. The only thing you need to solve outside React is routing, getting the data and making it available to your React components. Either use stores or pass all the data as `props`.

Thirdly, why Grunt? If you talk about a "dream team", I'd think Gulp is the current hotness, not Grunt. And you don't need either of them anyway, there is so little to configure that you don't even need a full-blown build tool.

I don't have a single line of database code in my React app. All the API calls are handled by a small wrapper around my database's domain-specific HTTP API. I could use the same API with zero changes for a native mobile app or a new web app that doesn't use any of the existing code. My web server is a dumb proxy for the database API and a pre-rendered for React (the pre-renderer essentially consists of a single line of JavaScript).

I can understand the appeal of Meteor, but it's not like anything you complain about has to do with React.

(Now Angular on the other hand... let's hope you don't need any prerendering ever.)

<comment><USER12> I am still using Grunt, and have been wondering how Gulp is. How do you like it? Why is it better?

<comment><USER11> I switched from Grunt to Gulp because I never liked Grunt's focus on configuration over code. But that's entirely a matter of taste. It's not "better" or "worse" than Grunt, it's just a different approach.

Gulp is pretty neat, until you try to integrate watch tasks. Want to run a transpiler whenever a file changes? Better don't have any compile-time errors or your stream will choke and die (without necessarily killing the process, mind you).

There are some workarounds (e.g. gulp-plumber), but depending on the actual tool you're trying to use they may not actually work -- or only work sometimes, which can be just as bad as not working at all.

Personally I've switched from Gulp to just putting scripts in my package.json file as god (or Isaac) intended. Every tool I want to use has a CLI anyway, and supports stdin/stdout, so it's all just Unix legos anyway. Except for browserify, which I replace with watchify in development for performance reasons (browserify in a large project can take a few seconds, watchify only updates the diffs).

</comment></comment></comment></comment><comment><USER13> I wonder if the criticism that the Flux team at Facebook has directed at two- way data binding is also applicable to Meteor. Jing Chen is her intro of Flux ([https://www.youtube.com/watch?v=nYkdrAPrdcw&list=PLb0IAmt7-G...](https://www.youtube.com/watch?v=nYkdrAPrdcw&list=PLb0IAmt7-GS188xDYE-u1ShQmFFGbrk0v#t=622)) says that two-way data binding creates a major challenge for scaling applications because views can trigger changes in data, and data changes can trigger cascading changes in views, which makes it very difficult to predict the behavior of the app as a whole. Wouldn't Meteor face the same challenges?

In other words, if you believe that the Flux design pattern (which involves a central dispatcher as the only entity capable of updating the data) is sound, shouldn't you stay away from Meteor's model when building large applications? Or am I missing something?

<comment><USER14> I don't believe Meteor has two-way data binding. You have to update the model manually using events[0].

0: [https://docs.meteor.com/#/full/eventmaps](https://docs.meteor.com/#/full/eventmaps)

<comment><USER5> Two way data-bindings are not a Core feature and they are implemented in packages. My favorite one is this: [http://viewmodel.meteor.com/](http://viewmodel.meteor.com/)

</comment></comment></comment><comment><USER15> I've read somewhere that a use-case of Meteor is to let you write your server- side logic in javascript, and then run the server-side logic on the client. Wouldn't that be clearly insecure, to trust the client with running server logic?

Also, this was accomplished years ago with Google Web Toolkit, which lets you write both the server & client in Java, and compiles the client-side java to very efficient, optimized javascript. That has the added advantage of letting you use a sane, strongly typed language, with all the productivity tools available for Java, and none of the quirks of javascript. [http://www.gwtproject.org/overview.html](http://www.gwtproject.org/overview.html)

<comment><USER4> If you read the docs you will see it's not implemented in an insecure way. The core meteor devs are pretty brilliant people, creator of etherpad, svn core contributer, early asana employee, these people aren't dummies they wouldn't do something that silly. Such a dumb thing would have been called out way before 1.0 wouldn't you think? Maybe give it a moment of thought before you comment.

<comment><USER16> > Such a dumb thing would have been called out way before 1.0 wouldn't you > think? Maybe give it a moment of thought before you comment.

To be fair, I'm pretty sure the previous versions _did_ have this issue -- it was just supposed to be ultimately fixed. I could be recalling incorrectly though.

<comment><USER17> It was fixed about two years ago in October of 2012, when they added the accounts system and allow/deny rules. Since then they've added additional security features such as the browser policy package.

</comment></comment></comment></comment><comment><USER18> Here's the official blog post announcement for Meteor 1.0: [https://www.meteor.com/blog/2014/10/28/meteor-1-0](https://www.meteor.com/blog/2014/10/28/meteor-1-0)

<comment><USER19> And here's a quick way to try it out in a click interactively in the browser: [https://www.terminal.com/tiny/F4bHKa1XiB](https://www.terminal.com/tiny/F4bHKa1XiB)

<comment><USER20> Or [http://meteorpad.com](http://meteorpad.com) \- the JSFiddle/Plunkr of Meteor.

<comment><USER21> Hehe, not yet supports 1.0 :)

</comment></comment></comment></comment><comment><USER22> I haven't looked at Meteor in a while, but am really impressed with how the vision of Meteor and the code (and of course the website) have evolved.

Meteor looks extremely simple to get up and started with, and I was thoroughly impressed by the implicit modularity of it all ("meteor create" makes like 3 files, I think that's awesome)

They really try (and succeed) to rid ourselves of the duplication on server and client. And if the android/ios support is as easy as it looks, this is an insanely useful framework.

I'm going to use it in my next project for sure now, just need to see how template/module composition works

<comment><USER23> Phonegap development is still phonegap development, even with Meteor. That said, I built a prototype chat app and deployed to iOS in about an hour. It really was that easy, and the app runs terrifically well. The "write once, run anywhere" mantra is a little more real with Meteor than with other approaches I've used before.

<comment><USER22> Thanks for sharing -- that's awesome to hear, yeah, Phonegap definitely has it's warts, but I like the idea of being able to at least get SOMETHING up so quick (to match the web interface

</comment></comment></comment><comment><USER24> While I do enjoy the bleeding edge on which we live. I'd love to wait to have the discussion about the new Meteor features until their site and newsletter tells us about the release.

Sure the git commit is a landmark, but there's nothing to offer other than 'kudos' with this link as the discussion point.

<comment><USER25> saym's comment refers to the original post, which pointed to a GitHub commit: [https://news.ycombinator.com/item?id=8522106](https://news.ycombinator.com/item?id=8522106).

We merged the stories (in our ghetto way) and moved the comments over here.

<comment><USER24> Sneaky! Glad to have a better discussion focus point. Thanks for providing context to my comment.

</comment></comment></comment><comment><USER26> When the first release of meteor came out, I was really impressed by the product. The real time update of the web page with zero code was an amazing feature. Today why I need of Meter?

Server side I have multiple choices that guarantee me heigh scalability, performance, and real time. Also the mongodb solo option, without sql is very restrictive.

Client side, there are great js frameworks like React, Ember and Angular that are great modular libraries.

<comment><USER27> I hoped they change meteor and opened it to other databases. The mongodb only option was the reason for us to stop using meteor.

Most of our customer projects use "old school" sql and only a few nosql- databases.

Waiting for Version 2 ;-)

<comment><USER26> I'm not really confident about new version the releasing of version 1 was too long. Also I do not see a strong open community that support them like Rails, Django o Node. Of course I wish them to grow in terms of contributors

<comment><USER11> There is a pretty distinct and active Meteor community, though from the outside it's hard to tell how much of that is just people who are interested in it because of the hype (kinda the problem MongoDB had) vs people who actually use it and know what they are doing.

I wouldn't say the wait for 1.0 is a good indicator of stability or success, though. Node.js is still at 0.x and so is React. AngularJS took a long while to get to 1.x but is now actively working on 2.0.

Many developers are cautious about when they dare calling a product 1.0. Until the idea that "if your code is in production, it's already 1.0" gained some ground, there was barely any code on npm that wasn't stuck in pre-1.0 land.

The real indicator is how much time passes between minor or bugfix releases. Ideally the latter should happen fairly regularly and the former not too often. If Meteor hits 2.0 anytime soon, that could be a worse sign than if it sticks with 1.0.x for "too long".

<comment><USER28> There is this tiny detail about Meteor, that is has been funded $11.2 million.

\- [https://www.meteor.com/blog/2012/07/25/meteors- new-112-milli...](https://www.meteor.com/blog/2012/07/25/meteors- new-112-million-development-budget)

\- [http://venturebeat.com/2012/07/25/meteor- funding/](http://venturebeat.com/2012/07/25/meteor-funding/)

</comment></comment></comment></comment></comment><comment><USER29> This is about books as learning resources.

For everyone looking to learn Meteor the first 8 chapters of Discover Meteor are available for free for the next week. It is probably the starting book for everyone :) [https://book.discovermeteor.com/starter](https://book.discovermeteor.com/starter)

Also the Manning book Meteor in Action is 50% off the next week with the code jiafinal50 The book is in heavy development with updates every couple of weeks. However it is still not finished and lacks some advanced chapters still. [http://manning.com/hochhaus/?a_aid=yauh&a_bid=aeff5509](http://manning.com/hochhaus/?a_aid=yauh&a_bid=aeff5509)

Apress also has a book called Beginning Meteor but it has almost no relevant content as of yet and no updates in the last months. [http://www.apress.com/9781430268369](http://www.apress.com/9781430268369)

All Packt titles are hopelessly outdated for version 1.0, so you better stay away from them.

<comment><USER30> Also, as a shameless plug, beginning web developers are quite fond of my book about Meteor:

[http://meteortips.com/book](http://meteortips.com/book)

It'll be a couple of days before a (completely) revised version is released for 1.0 though.

(Reviews can be found on Amazon: [http://www.amazon.com/dp/B00MA8KVAY](http://www.amazon.com/dp/B00MA8KVAY))

</comment></comment><comment><USER31> Thank you Meteor team - you have done fantastic work, what an achievement. I've had a blast building my meteor hobby site [1]

[1] [http://quantpapers.com](http://quantpapers.com)

</comment><comment><USER32> This is really awesome, I just checked out the new website and docs. Everything is so much more clear, I love the new docs. Stuff is laid out really well, people new to Meteor are gonna really like this.

</comment><comment><USER33> Hey Meteor Folks, [https://www.meteor.com/main](https://www.meteor.com/main) says Preview 0.9.4. First place I went after I checked the git repo.

<comment><USER5> The release 1.0 is pushed to git but there is still work to do: docs, web- site, announcements, etc.

It is not done yet :)

</comment></comment><comment><USER34> Great job, Meteor has really helped me develop my programming skills as a beginner. It allows me to get instant feedback on the code I write. To see a real world prototype keeps me going!

</comment><comment><USER35> How does one start a project like this and get paid? What are the revenue sources for the team? It's a great product, and the fact that it's open source is amazing.

<comment><USER36> Step number one:

Create an awesome framework that people want to use (Meteor started out as a travel guide site, I believe, and other YC batchmates wanted to use their web framework)

Step number two:

Keep building the web framework

Step number three:

Raise money to keep building that framework, with a partner who believes for the long term

Step number four:

Keep being awesome, and become the tool that a ton of devs want to use

Step number five:

Monetize with your own enterprise support and hosting

<comment><USER37> "I think you should be more explicit here in step 3"

[http://i.imgur.com/uvulagb.jpg](http://i.imgur.com/uvulagb.jpg)

</comment></comment></comment><comment><USER38> I absolutely love Meteor. I've been evangelizing it a lot this year. I wish someone at Meteor would reply to my emails. _wink_ ;) email@example.com

<comment><USER20> I applied too, they were in a hiring freeze before 1.0 :-)

</comment></comment><comment><USER39> Meteor is already easy to setup, but for those of you on Windows or who want a clean sandbox to develop meteor apps, we launched a custom Meteor template on Nitrous today. We also increased the free resources:

[http://blog.nitrous.io/2014/10/28/meteor-template-on- nitrous...](http://blog.nitrous.io/2014/10/28/meteor-template-on-nitrous- io.html)

</comment><comment><USER40> How did Meteor get to 1.0 when node.js is still at 0.10? I congratulate the Meteor team, but can anyone confirm it is actually stable?

<comment><USER41> Meteor hit 1.0 b/c their APIs are stable. I'd also guess that the software has hit a level of maturity where the Meteor team is comfortable with a supported release.

As for Node, there are some within the Node community who would like to bump it to 1.0 as it is clearly production ready. In Node's case, .1 vs. 1. is a just a numbering scheme issue, not a production ready issue.

</comment></comment><comment><USER42> Congratulations to the Meteor Development Group! I've been using Meteor for 16 months now and it's amazing how much it has changed/improved. It is a great tool to learn for any beginner web developer.

Also check out a catalog of the best Meteor learning resources at [http://MeteorHelp.com](http://MeteorHelp.com)

</comment><comment><USER43> UI & API in one go?

I just went through the tutorial on meteor.com, and I'm impressed with the speed of getting results.

When I were to build another online app, I'd split that in building the frontend and the API composed from microservices, so that I'd be able to offer access through the UI _and_ the web API. Is Meteor a good choice for this approach?

<comment><USER20> You can create REST points from Meteor collection very easily - [http://www.meteorpedia.com/read/REST_API](http://www.meteorpedia.com/read/REST_API)

</comment></comment><comment><USER44> First of all - absolutely love meteor. Couchbase/CouchDB support would be fantastic! More (NoSQL) database support would be fantastic. I worry that it's so MongoDB specific now and the "scale" technologies are MongoDB specific (Oplog tailing only) that adding other databases in the future will become a lot more difficult.

<comment><USER45> Check out [http://hood.ie/](http://hood.ie/) its CouchDB based and has some similar concepts to Meteor

</comment></comment><comment><USER46> I am excited to give Meteor a go and take advantage of its isomorphic nature.

I am particularly excited by the potential of being able to swap out Mongo for RethinkDB ([https://github.com/tuhinc/rethink- livedata](https://github.com/tuhinc/rethink-livedata)).

<comment><USER10> That project has been abandoned, it seems, and wouldn't work with 1.0.

</comment></comment><comment><USER47> [https://www.meteor.com/install](https://www.meteor.com/install)

curl [https://install.meteor.com/](https://install.meteor.com/) | sh

This despicable habit rears its ugly head again.

<comment><USER48> Just curious. What is wrong with this?

<comment><USER49> [http://blog.existentialize.com/dont-pipe-to-your- shell.html](http://blog.existentialize.com/dont-pipe-to-your-shell.html)

</comment></comment></comment><comment><USER50> Nice i love meteor, i hope that there will be some work on a sql backend.

I want defined database strucures ;)

<comment><USER51> Absolutely necessary, I agree.

</comment></comment><comment><USER52> Congrats to the team - maybe it's just me, but it seems like you guys to to 1.0 pretty quickly

edit: random aside, I literally just saw the transition from the preview website to the 1.0 website as it was hotswapped in, and I have to say it looks _much_ nicer!

</comment><comment><USER32> Wow that was fast, I can't believe Meteor is already at 1.0! This is really exciting times, so much progress has been made with Meteor. Ill upgrade my meteor app as soon as the official release is out.

</comment><comment><USER53> Kudos, Meteor team! Now, SQL, please...

<comment><USER4> You can have SQL already, use ddp methods to query a database on the backend. It's not reactive, but it enables you to use SQL.

<comment><USER54> The data isn't reactively loaded in realtime, but Meteor itself is still reactive. What I mean to point out is that even if you're depending on say classic JSON APIs, the meteor app within itself can still do reactive-features (templates, local collections, etc). And depending how you implement things, you could still take advantage of push capabilities for your data from a legacy endpoint.

But yes, I agree, it's not ideal until a SQL adapter is available.

</comment></comment></comment><comment><USER55> Meteor is awesome, congrats to the Meteor team for their 1.0 release! I've been using Meteor for over a year now, and it is staggering how far it has come. They've addressed and continue to address just about any concerns the community has brought up, from security to speed to tools, etc. And where they haven't, the community has stepped up huge. Seriously, Meteor is amazing, but what makes it even better is the awesome community surrounding it. Congrats again.

</comment><comment><USER56> seems like their selling point is data binding + client syncing. Considering I can do that with Ractive/React + Firebase, what's the advantage of using Meteor?

<comment><USER57> You can ask it either way.

seems like their selling point is data binding + client syncing. Considering I can do that with Meteor, what's the advantage of using Ractive/React + Firebase?

<comment><USER56> For starters:

1\. You can reuse your existing API, or choose the stack you're comfortable with (I prefer Python to Javascript and Postgres to Mongo)

2\. They are being used in production by high traffic websites (Guardian and Instagram respectively), so they're more battle tested

3\. Their press releases aren't loaded with buzzwords and hyperbole

<comment><USER17> The reasons I prefer Meteor (in no particular order):

* Fully automated build chain. No matter what kind of preprocessors I use, all my code is compiled, bundled, and hot reloaded into the application. CSS updates are automatically live injected into running applications without a browser refresh. I don't have to write any build chain code, just application code.

* Isomorphic client/server APIs, with code sharing built into the build chain. I'm using the same language with the same APIs in both environments, drastically decreasing redundant code. Clients can simulate server RPCs using the same function as the server while it waits for the server's response. If I want, I can easily make the client's simulation code different from the server's such as when I want to obfuscate something, or simply disable client simulation for certain RPCs. The package system incorporates both server and client assets, allowing drop-in full-stack components, such as...

* The Accounts UI component. A drop-in, automated SRP+OAuth authentication system that's easy to customize and restyle, or build from scratch using the simple JS authentication APIs. It takes minutes to make a web application with a fully-featured and secure authentication system with password-based and 3rd party OAuth login methods. And logging in never requires a refresh.

* Already glued together. Endpoints don't have to be hooked up; they're hooked up from default. Publish data on the server. Subscribe on the client. Add authorization rules, and I have a fully functional web application with realtime data updates, with virtually no glue code.

<comment><USER49> Great overview of the benefits!

</comment></comment></comment></comment></comment><comment><USER54> Not official but here is the a change log: [https://github.com/meteor/meteor/blob/fb7466078ec5da90321bdc...](https://github.com/meteor/meteor/blob/fb7466078ec5da90321bdca3f08ddf085775e947/History.md#v10)

It's a bit light on details. I wouldn't say Meteor is 1.0 yet, but preparing for it. Also Worldwide Meteor day is Nov 6th, I anticipate a more formal announcement then.

</comment><comment><USER58> The importance of JavaScript as a Platform is not abt billions of browsers running JS, but abt how each one of them is also a JS IDE. If we could click the fork button, and start editing, testing and deploying right away, all within the browser, we'd probably get programmers to contribute to open source web apps in a way never seen before.

A sea change in how web software gets built and consumed, in the same way Britannica yielded (had to) to Wikipedia.

</comment><comment><USER3> Amazing :D Great work, and hats off to the meteor team! I just finished a hackathon this weekend with a meteor app, and absolutely loved the framework.

</comment><comment><USER59> For an unbiased overview of Meteor, including what it offers and how it differs from typical JavaScript frameworks (like Angular.js and Backbone.js) and ecosystems (like Mean.js and Yeoman), read this article: [http://javascriptissexy.com/learn-meteor-js- properly/](http://javascriptissexy.com/learn-meteor-js-properly/)

</comment><comment><USER60> When I saw a link to an "Atmosphere" page I was curious what did meteor had to do with the Atmosphere project [1], a "real Time Client Server Framework for the JVM, supporting WebSockets and Cross-Browser Fallbacks Support". The answer: nothing.

1: [https://github.com/Atmosphere](https://github.com/Atmosphere)

</comment><comment><USER61> Trying to figure out how it works. And saw this in one of the paragraphs:

> No longer do you need to provision server resources, or deploy API endpoints > in the cloud, or manage a database

So you don't manage a database, but what happens to the data.

Can anyone trace an example, I don't, order or cart update from client code to persisting it on the back-end somehow? Does it use flat files...?

<comment><USER62> It uses a database, specifically MongoDB. But as I understand it, Meteor manages this for you itself, and abstracts the orchestration of those things into the Meteor platform itself.

It's just a higher level of abstraction, not a new technology. And certainly not flat files.

<comment><USER61> MongoDB? I think to be accepted and taken more seriously they'd have to at least have an option for something else.

<comment><USER47> I say PostgreSQL. Not only can it do everything MongoDB can do (and faster* too), it's time-tested technology.

* [http://blogs.enterprisedb.com/2014/09/24/postgres-outperform...](http://blogs.enterprisedb.com/2014/09/24/postgres-outperforms-mongodb-and-ushers-in-new-developer-reality/)

</comment></comment></comment></comment><comment><USER63> Hi meteor.com team. I've scanned the home page and even looked at some other links on the site. I still don't know what this does. Is it a javascript library? Or template maker? A project packager? I have a lot to do and very little time. Can you make a quick video that describes why I should use Meteor and what it does for me? Thanks!

<comment><USER64> Basically, yes to all.

In terms of scope it's roughly as encompassing as something like Rails - it's full stack.

<comment><USER63> Ah thanks. But if Rails is my coding platform of choice how does this integrate into it?

<comment><USER65> It doesn't, this is a separate coding platform. If your coding platform is Rails, you don't integrate Django into it.

</comment></comment></comment></comment><comment><USER4> I used my meteor developer account to get the free discover meteor book (via the limited time 1.0 promotion I guess), but I thought I did something wrong, tried again and ended up with two copies/purchases. It was free, but seems like a bug. Maybe detect if someone already got a book?

<comment><USER66> We fixed that. Thanks for pointing it out!

</comment></comment><comment><USER67> At this point, what percentage of web development can't/shouldn't be done with Meteor? It seems like everything else is obsolete in comparison. The only non- Meteor cases I can think of involve especially large scale.

<comment><USER68> Because Meteor hides much of what's really going on, it's sometimes hard to understand just how the app is working. At least that was my impression of it when I tried it about 9 months ago.

Choosing a stack on your own means more time is spent making things work, but then you know how it works. That's why I went for a MEAN stack instead of Meteor. But I'm going to try Meteor again soon!

<comment><USER69> While Meteor does do a lot for you out of the box, it doesn't really prevent you from seeing what's going on. There are some good resources for seeing what Meteor is doing behind the scenes (meteorhacks.com and eventedmind.com) if one does want to dig in.

</comment></comment></comment><comment><USER70> Congrats to the Meteor team on 1.0! We're building our app [http://servicelocale.com](http://servicelocale.com) on it for high quality services & crafts in Australia.

<comment><USER71> Looks great but the site doesn't feel very snappy.

<comment><USER72> I haven't found a Meteor site that does yet, I would love to see an example of one where I don't have to sit at a loading wheel. Anyone?

<comment><USER20> [http://meteor.com](http://meteor.com) is very snappy. So are sites using fast-render, see [https://meteorhacks.com/fast- render/](https://meteorhacks.com/fast-render/)

</comment></comment></comment></comment><comment><USER73> i am super excited to see the launch

quick feedback: this scares me off a bit:

200 open issues / 150 stale branches / 42 open pull requests

might be normal for open source projects of that size though

<comment><USER74> On the contrary, I think that is a good sign. It means there is an active community that is opening and contributing to issues. If you check out Rails' repo ([https://github.com/rails/rails](https://github.com/rails/rails)) you'll see the same thing. If you've ever been an open source maintainer, you'll know that you'll inevitably write bugs and so you'll always have open issues. The scary thing would be if no one filed any issues or had any pull requests.

<comment><USER73> good point

cycle times might be better indications

</comment></comment></comment><comment> nathan-muir Congrats to the Meteor team!

We've built an enterprise/b2b app on meteor, and even through all of the hard yards, it's been a success & the right choice for us.

When I first heard about meteor, back at v0.5 or v0.6 - I watched the video from their home page, and thought it was full of buzzword bullshit. I didn't have a clue what it did.

I then ended up reading about how their latency-compensation API system worked [Meteor Methods]; And instantly knew that it was for me.

Having an API that simulates itself on the client, while simultaneously performing the same work on the server, is freaking awesome. (And then rolls back automatically if they don't agree).

 __If you are building a real-time, collaborative tool. Meteor is the framework. __

That being said, there are a few questions about integration & scalability.

Opportunities to use Meteor:

* If you can make something small, eg. an internal tool [Free mobile app with cordova!]

* If it matches a certain feature of your app - and you can segment it based on URL (eg, it's a separate app)

* You're a sadist, and you're going to port your whole app to meteor...

* You're writing an MVP and you're going to scrap it later

* You're product has realtime/ collaborative elements that are a SELLING feature [not just for your personal enjoyment].

Scalability:

* Client are always connected via websocket. Great for realtime data (no polling), crap for a website.

* As meteor instances are single threads, you can run multiple instances on the one server. Design you code for this (eg, don't store state in regular JS variables on the server - all has to be in the database). Load balance between them.

* Once the "client" has booted up. You can then connect to as many other DDP servers [backed by their own mongo instance, or the same mongo instance] as you like. This gives you the ability to segment your application based on your core feature. EG; if you're a monitoring app, shard your data by client, if you're a document app, shard by project. Have a central listing which tells them which server to connect to.

* Perform heavy lifting somewhere else. Plenty of "web workers" out there, or roll your own using Celery & Meteor-Celery package [shameless plug].

All in all. Meteor is great at what it does; and what it does, is going to be the next generation of web apps.

<comment><USER75> > * You're product has realtime/ collaborative elements that are a SELLING > feature [not just for your personal enjoyment].

What opportunities exist in the enterprise market that specifically benefits from this feature?

<comment><USER20> I'm working on Google's Governance, Risk and Compliance management system.[1] Porting it to Meteor would accomplish several goals:

* clean and much simpler code base

* automatically (reactively) updated status reports on compliance across various systems depending on numerous components throughout Google in continuous flux

* ease of onboarding new developers in the team given the simplicity and ease of learning of Meteor

[1]: [https://github.com/reciprocity/ggrc- core](https://github.com/reciprocity/ggrc-core)

<comment><USER75> I worked with Meteor.js on an enterprise app a year ago but it seems to be more mature now. I think this is a great time to begin porting it.

</comment></comment></comment></comment><comment><USER76> Just started using Meteor + Telescope on my site TravelMo.re and love it so far. Really easy to use, kind of a pain in the butt to deploy.

<comment><USER6> Could you elaborate on why it is a pain to deploy? I've never used Meteor but I thought one of the selling points is ease of deploy, hot code pushes, stuff like that.

<comment><USER36> [Not the op] Meteor is extremely easy to deploy.

Disclaimer: I think Meteor is fantastic.

Never really had an issue - I can't say the same about rails! Obviously Meteor has the advantage of being younger and so less cruft has built up, but I'd bet on it still being insanely easy to deploy 4 years from now.

The Meteor team is doing an awesome job spending the VC money on making an experience that is fantastic for devs. Major props to Geoff et al.

<comment><USER23> Deployment depends on where you want to run it. Builds into tarballs that can be deployed pretty directly onto EC2 or other hosting services. It does require a VPS or equivalent system (LAMP hosts won't run Meteor). I understand Heroku can be a little more complicated as well. That said, Meteor's self- hosting option is pretty good for getting started, and Amazon instances run it very well.

Also +1 on the Major Props to the Meteor team. They are a model team.

</comment></comment></comment></comment><comment><USER77> Congrats to the team! This is a very serious engineering achievement. I'd imagine it wasn't nearly as easy as they made it look.

</comment><comment><USER78> Congrats Meteor! but I really find it loading a bazillion javascript files a bit of an overkill. Also debugging is a pain in the butt.

<comment><USER17> In production in bundles and minifies all JS and HTML into one file that is sent to the client. Then all further communication happens with JSON over WebSockets/SockJS. If changes are made to the JS/HTML, the server will send down a new application bundle and hot-reload the app without interrupting the user if you are storing the user's app state in the Session.

The CSS is also bundled in production. When further changes are made to the CSS, the new stylesheet is live-injected into the running apps without reloading the browser.

</comment></comment><comment><USER79> I see this in example code:

        if (Meteor.isClient) {

I don't get it. Are we shipping server side code to the client?

<comment><USER80> Not unless you want to. Anything in a `server/` or `private/` directory is not sent to the client. This pattern is sometimes used to group similar functions in a single file.

Relevant section of the docs: [https://docs.meteor.com/#/basic/filestructure](https://docs.meteor.com/#/basic/filestructure)

</comment></comment><comment><USER81> Congratulations to everyone on the Meteor team on 1.0! I feel this is just the beginning of many great things to come!

</comment><comment><USER82> What is the status of supporting Redis. I'd be more excited if I could use my favorite instead of Mongo.

<comment><USER5> I and another Core Dev Justin SB worked on the Redis support for a month: [https://atmospherejs.com/slava/redis- livedata](https://atmospherejs.com/slava/redis-livedata)

It has seamless support for hashes and strings, miniredis, latency compensation, user input validations - similar features to MongoDB integration.

Right now you need to start the Redis server and set up the KV observations manually once for every Redis server you intend to use.

This support was experimental and we didn't develop it further from there. We told our community about it on a Meteor Devshop but there wasn't much interest. If there will be more interest, we will continue developing it.

</comment></comment><comment><USER83> Congratulations and thanks, Meteor team!

</comment><comment><USER84> What is meteor's revenue model?

What am I missing...

<comment><USER20> Galaxy, an enterprise-grade, multi-tenant hosting environment for Meteor apps - [https://www.meteor.com/blog/2012/07/25/meteors- new-112-milli...](https://www.meteor.com/blog/2012/07/25/meteors- new-112-million-development-budget)

<comment><USER85> For a second there I was like "Woah! $112M?". Damn friendly-URL's.

</comment></comment></comment><comment><USER86> Yay! Congrats to the Meteor team!

</comment><comment><USER87> Well done, Meteor team. My project based on Meteor is going to finished this Friday.

</comment><comment><USER88> Thank you Meteor team. I really enjoy working on my web app that I made with Meteor.

</comment><comment><USER89> Congrats Meteor, great times!

</comment><comment><USER90> The inevitable will come soon News headline: Google buys meteor

</comment><comment><USER91> Congrats Meteor team!

</comment><comment><USER92> Congratulations, and great pun for the title. :)

</comment><comment><USER93> Are there any similar applications like meteor?

<comment><USER94> I think [http://derbyjs.com](http://derbyjs.com) can be seen as a competing framework.

</comment></comment><comment><USER95> Congratulations!!

</comment><comment><USER96> Awesome, really excited to the 1.0!!!

</comment><comment><USER97> Awesome! Really excited for this.

</comment><comment><USER7> congrats guys :) Very excited to be a part of the community.

</comment><comment><USER98> Grats Meteor!

</comment><comment><USER99> congrats to meteor team!

</comment><comment><USER75> So last time I used this was back in August 2013.

The main concerns we had was scalability and reliability.

How does 1.0 address the previous concerns that was enough to abandon meteor.js altogether?

<comment><USER20> See this previous reply: [https://news.ycombinator.com/item?id=8522918](https://news.ycombinator.com/item?id=8522918)

</comment></comment><comment><USER100> FYI: this link gets me into a redirect loop (probably because of something NoScript related)

<comment><USER101> Don't expect to see meteor-based sites work with JS disabled.

Not a huge fan of this turn of events, either...

</comment></comment><comment><USER102> If only this was built in Dart... or at least TypeScript.

<comment><USER103> I am grateful that it was built in neither.</comment></comment>