A Tale of Two Students - <AUTHOR> http://online.wsj.com/article/SB10001424052748704717004575268752238805736.html?mod=WSJ_newsreel_lifeStyle <comment><USER2> This article seems to be implying that Laura is somehow less of a success than Ivan, but is that true?

Laura has, without support, involved herself in organizing volunteer activities, successfully sought out a scholarship _and_ leveraged her connections to do it, showing great initiative.

She also seems to be committed to working to support herself as needed, and she still made an effort with school.

Is there any reason to think that she'll be less of a success in life than Ivan? Is college really the only end game for success?

<comment><USER3> In fact; is she not already more of a success.

</comment></comment><comment><USER4> This is a WSJ "Saturday _Essay_."

It is _descriptive_ , a case study (of two cases).

There is no way of assessing what significantly differing factors (besides their high schools) were unmentioned/unknown yet influencial for these two teens.

It establishes no causation.

Only value of article is to demonstrate some of the strategies/opportunities that a charter school _may be_ at liberty to exploit. Oh, how severely education suffers from lack of capable research.

<comment><USER5> The vast majority of social research doesn't establish causation either. It's an extremely difficult task for large, complex, disorganized systems (e.g. social systems, economies).

</comment></comment><comment><USER6> >Santa Fe South, whose teachers are on a one-year renewable contract, can remove incompetent instructors more easily than Capitol Hill, where teachers are unionized.

It seems to me that this is probably the most important distinction (though not the only one, of course). There were some _unbelievably_ bad teachers in the town I grew up in, and my town was ranked #14 in NJ in 2006 (I left that school system in 2002, but from my younger siblings I know it can't have improved much). Teacher quality makes or breaks an education.

</comment><comment><USER7> Great article, but it completely misunderstands the point of charter schools. Charter schools are suppose to be a testing ground for new methods in public school administration. If a charter school is successful, it's methods are suppose to be implemented on a wider range of public schools.

Maybe I'm misinterpreting the tone of the article but it seemed to be suggesting that charter schools in themselves were a viable replacement for normal public schools.

<comment><USER8> And why not?

<comment><USER7> Maybe I just wasn't being clear, I'll try and elaborate. Both public schools and charter schools are publicly funded. Usually the difference in the two is that charter schools get less funding per pupil in exchange for not having to adhere to the same administrative and academic standards.

My only point was that the article seemed to be suggesting that charter schools are good and public schools are bad (which doesn't make any sense since they are both public schools) and that in a perfect world charter schools would replace public schools (which doesn't make any sense because then, by definition, they wouldn't be charter schools.)

Remember, charter schools are given more freedoms so that they can experiment and see what practices work. The original idea was that the successful experiments would be used in normal public schools. There are lots of truly superb charter schools and some pretty bad charter schools.

I'm all for charter schools and I'm all for implementing successful practices in public schools. However, in my experience the people who want to "replace public schools with charter schools" either don't understand what charter schools are, or just want to cut the budgets of public schools.

There are plenty of people who advocate more funding for charter schools, and I am one of them. But in the public school reform movement there is almost no one who advocates expansion of charter schools instead of wider implementation of the successful practices of charter schools.

<comment><USER8> Thanks.

Perhaps those people use different definitions of "charter schools", because they do not know about the legal definition?

I for one, would like to see schools in general given more autonomy to experiment and responsibility. Of course pupils should be free to choose their school then, too.

</comment></comment></comment></comment><comment><USER9> _One of the biggest obstacles is that most parents assume college is out of reach_

 _The school is fighting an uphill battle to change an ingrained "mentality among lower socio-economic [students] who believe they cannot make it_

Whether it's education, economics, politics, work, and yes, even start-up culture, this is a recurring theme that can't be ingored:

The first step in achieving anything is believing that you can.

Nice story. Thank you, robg.

<comment><USER10> "The school is fighting an uphill battle to change an ingrained 'mentality among lower socio-economic [students] who believe they cannot make it,' he says."

There is indeed a set of barriers faced by high-ability, low-income students that is not faced by low-ability, high-income students.

[http://www.businessweek.com/magazine/content/03_27/b3840045_...](http://www.businessweek.com/magazine/content/03_27/b3840045_mz007.htm)

<http://www.educause.edu/ir/library/pdf/ffp0621.pdf>

<http://www.educause.edu/ir/library/pdf/ff0615S.pdf>

<http://www.tcf.org/Publications/Education/carnrose.pdf>

[http://www.tcf.org/Publications/Education/kahlenberg- affacti...](http://www.tcf.org/Publications/Education/kahlenberg- affaction.pdf)

<http://harvardmagazine.com/2005/05/a-thumb-on-the-scale.html>

[http://www.theatlantic.com/doc/200511/financial-aid- leveragi...](http://www.theatlantic.com/doc/200511/financial-aid-leveraging/4)

<http://www.thecrimson.com/article.aspx?ref=510012>

<http://www.equaleducation.org/commentary.asp?opedid=1240>

[http://www.jkcf.org/assets/files/0000/0084/Achievement_Trap....](http://www.jkcf.org/assets/files/0000/0084/Achievement_Trap.pdf)

<http://www.reason.com/news/show/123910.html>

It's very commendable for school principals to encourage students from poor families to keep pushing at those barriers. Meanwhile, principals of high schools in higher-income areas don't need to do the same kind of encouraging for academic preparation, because families in those areas know that their children can get into college even if they are very poorly academically prepared for college.

</comment></comment><comment><USER11> I find the following interesting:

Charter School:

Able to kick out students at will for things like possession of drugs, or violence. So you immediately know, no shit or you are out.

1-year renewable contract with teachers, so only good ones stay.

Ability to keep school student size relatively small.

Sounds like a real business. Maximize your efficiency. Get the best workers, ensure they are the best, and ensure the best results given your merchandise. Ok not quite 1:1 but close.

Now how to do this on a national level to ensure the best everywhere!!??! I guess the moral of this story that I got is that once the students were properly motivated the flourished, until then nothing good was happening. It is not just teaching, but sparking a curiosity of why they should want to learn.

</comment><comment><USER12> People who want to be Politicians disgust me.

Good politicians don't want to be Politicians, they want to be because they know that they're the best one for the job, making things better for themselves and for others.

The problem is that this guy is in the majority, the high majority of people who become Politicians.

<comment><USER13> <http://en.wikipedia.org/wiki/Cincinnatus></comment></comment>


Heroku wants to sell to salesforce - <AUTHOR> http://cot.ag/f7gsur

<comment><AUTHOR> and heres the link to salesforce blog : [http://blog.sforce.com/sforce/2010/12/what-i-love-about- hero...](http://blog.sforce.com/sforce/2010/12/what-i-love-about-heroku.html)</comment>


Dark emerges with 'deployless' software model - <AUTHOR> https://techcrunch.com/2019/07/29/dark-emerges-from-stealth-with-unique-deployless-software-model/ <comment><USER4> > If you build your application in Dark's language inside of Dark's editor, > the reward is you can deploy it automatically on Dark's infrastructure on > Google Cloud Platform without worrying about all of the typical underlying > deployment tasks.

> ... Ellen Chisa, CEO and co-founder at the company, admits that the Dark > approach requires learning to use her company's toolset, but she says the > trade-off is worth it because everything has been carefully designed to work > in tandem.

So this "deployless" method is really you just offset the deploying mechanism and control (probably to varying degrees) to a third party that's dependent on another third party. I don't buy that. There are so many tools that make web application deployment simple and easy without constraining what tools you get to use and what platform you get to run it on.

I'd have to look more at the project itself, but just reading that article I have a number of concerns/questions with this idea. I would be interested in who they are trying to market this to. One size fits all sounds great in theory, but rarely ever works out well in practice.

<comment><USER5> > offset the deploying mechanism and control (probably to varying degrees) to > a third party that's dependent on another third party

This sounds exactly like working inside any big company, and all that pre- canned infrastructure is a huge benefit to any project

It will be interesting to see what they've built in the cold light of day, and whether it delivers. I'm apparently not nearly as pessimistic as others on this thread

<comment><USER4> For small things you don't want to think about or tiny/solo teams, I could see a use case for this. But the product has to be really, __really__, fantastic for bigger groups to consider the control trade off.

I'm not bashing on the product, I'm heavily apprehensive of the model for the situations I'm involved in. I can say with certainty it'd never make its way into my current place of employment for several reasons.

<comment><USER6> The game is never to target the big teams. But make the development leaner for coming generation and smaller teams that they basically own the complete idea. This dependency play is what Google always does. Create the infrastructure, let others do the hardwork. Though I am skeptical too of the efficiency of the tradeoffs.

</comment></comment></comment></comment><comment><USER7> I'm excited by almost everything about this. I think it could be transformational in some categories of software engineering, but I do have a big concern...

> I think the biggest downside of Dark is definitely that you're learning a > new language...

But this is not it. Learning new languages isn't that hard, and a language so well designed for an ecosystem would likely be a pleasure to use. They are probably giving this as their "big downside" because it's not actually their big downside.

The real big downside is proprietary lock-in. My tools right now are open source, developed in the open, things I can contribute to or at least understand at a fundamental level. "Python" can't go out of business, "Postgres" won't get acquihired and shut down with 30 days notice, and Docker images can run on plenty of hosting providers where there's lots of competition.

While I might bet a company on a new technology I'm not going to bet a company entirely on the whim of a company, who may pivot, get bought, shut down, raise prices, etc. Hosting is the closest I'd get to this level of lock-in, but if that changes I don't have to rewrite all of my code, reproduce business logic, and also rewrite from a high level language like Dark to something that doesn't provide any of the same primitives.

<comment><USER8> Founder here. Totally fair concern - we're not thrilled about the lock-in either because we want people to try Dark and see that it solves a problem for them. We're looking at ways to improve this - would love ideas, and will be writing up some of our ideas soon.

Around some of the specifics: we've no intention of pivoting. If we discovered that Dark had a massive opportunity to be the AirBnb for market analytics (or whatever) we would 100% ignore it and keep doing what we're doing. Around pricing, we want Dark to be super cheap. Our intent is to be "within 2x of running the same app written in Node on AWS". We saw how much people leave Heroku because of the premium pricing and we don't want that to be us.

The other stuff is valid and we're looking for ideas here. Would it solve your problem if you were able to export a mostly similar working node/python/go app from your Dark program? Would it need kubernetes configs or to run on Heroku? Would you prefer that it be semantically exactly the same but the code is ugly, or with the code having the same look-and-feel but slightly different semantics?

<comment><USER9> Your vision is extremely compelling and well articulated.

I'm not sure I buy the "coalescing multiple things into one makes things simpler" argument - the simplicity comes at the expense of expressiveness, flexibility and optionality. A large, highly-opinionated monolith, right the way across the stack, is bound to have made some design trade-offs and decisions that are either plain wrong (we all make mistakes) or don't fit with however I want to actually use it.

To do this at the AST graph/language level strikes me as both genius and absurd - not only is language design very hard, but you clearly have a massive uphill struggle to provide sufficient library and framework-level code on top of that to be able to start to compete with more mature options. Not to mention things like code review tooling (it's neither text-based, nor even in any form of conventional revision control system, so likely start from scratch). Security controls, auditability, vulnerability management for any library ecosystem that springs up around this, etc. etc.

By rejecting text you are having to reinvent and support a compiler, an IDE, github/gitlab (or equivalent, with their massive functionality set including protected branches and security controls and the like), package management maybe, debugger tooling (on the web), release/rollback systems/UIs, perhaps even monitoring and alerting (because you're promising the users they don't need to run infrastructure/services like Prometheus and the like and your "roll out" process looks so different).

Does Dark really have sufficient expertise around all of that to want to make this stuff totally monolithic? Is it even possible for a startup company to really compete in that sort of global (massively open source) scene?

Convincing people to bet their company on your company, both as an ongoing enterprise and as a place that can get all the inherent trade-offs here well- matched to their individual use-cases is going to be an almost impossible sell. Regardless of how much you assert that you believe in your mission and don't want to ever pivot. You can't blame people for being sceptical, especially when the opening paragraphs essentially say "this is a silver bullet".

I wish you luck.

<comment><USER8> Thanks!

If you want to use all that stuff, you can do that today. You can use GitHub and Go and Phabricator and Prometheus and whatever you want. People who want to a take a conservative approach have a million different options. Honestly, just run your app on AWS, it's got everything you need.

What we're trying to do is something different, removing a ton of stuff that we think we can allow you not need. And maybe it won't work for a whole lot of people - that's fine. Over time we'll fill out more of the product and support more use cases.

<comment><USER9> I made a mistake mentioning Prometheus - it's the least important point in my post. I get that you may provide something for monitoring (performance and tracing, at least) that's more baked into the whole AST/graph model and that sounds really very compelling. And obviously end developers won't need to monitor the systems/services because as far as they're concerned there aren't any. It feels a bit like electric cars - a bunch of new (and hard) problems arise, but it's compelling as a bunch of older (also hard) problems just cease to be. Huzzah. I'll certainly agree with you that the potential upsides here are very large and very compelling.

But the need for things like code review tooling, test coverage reporting and mocking frameworks (yes, I will want to isolate stuff via mocks) aren't going to just disappear with this kind of model. They're far from exotic use cases for the kind of business customers you will need to scale this and get real adoption and thus positive cashflow, more of a necessity. It's a real leap of faith to think it's worth rebuilding so much of these kinds of ecosystems that have taken thousands of man years to evolve and develop for existing languages. And if you don't have plans to provide that sort of thing you'll be missing out on most of the market, I would have thought. Yes, you'll get hobbyists but surely they won't provide the volume or reliable subscription- style revenue you'll surely need to make this sustainable?

Unless of course your endgoal here is being bought out by Google, in which case fair play. This is cutting edge thinking and tech, full of nice hard problems to work on and lovely "oh but if we just don't have that then we don't need this either, or can do this like that instead" type insights to be made. Cool stuff, but it still won't get me to bet the farm on it. I really do wish you well though!

<comment><USER8> > And if you don't have plans to provide that sort of thing you'll be missing > out on most of the market

Realistically, we're not going to have all those things at launch, but we will have them later.

I don't think you're correct to say that it's not possible to get revenue without supporting every single thing that a customer might possibly need.

The people who are good matches for using Dark are people who don't mind that they're missing, including companies who are willing to pay. When we add them later, the people who needed those can start using it.

</comment></comment></comment></comment></comment></comment><comment><USER10> I've played with some early betas of Dark and I must say being deployless may make a good headline, but there are many more-exciting features. There's visual programming, a concise OCaml-style language, a unique pub-sub mechanism baked right in, and integrated database support. It's a really fresh approach.

<comment><USER11> > deployless may make a good headline, but there are many more-exciting > features. There's visual programming, a concise OCaml-style language, a > unique pub-sub mechanism baked right in, and integrated database support.

So, everything that is currently delivered in the real world by technologies like OutSystems, which have an enterprise customer base, 1-click deploys, and that you can actually try for free.

<comment><USER12> "Starting at US$6,250/month (Billed Annually)"

No lunch is free, the small plan is a single dev and max 100 users. Which means, once you go have 101 customers you'll have to charge users at minimum 62,5$/mo just to cover expenses.

I'm not saying that's not cheap for what you get, but the "free" constraints are there.

</comment></comment></comment><comment><USER13> The tone here is _extremely_ cynical.

Before you jump from thinking a specific feature is wrong, to asserting the whole project is a waste of time: please take a moment to consider where your broad assertion might be wrong.

In the words of Sam Altman: "it's easy/fun to say every new startup you hear about is bad. you will usually be right. you will never be successful."

[https://twitter.com/sama/status/571733273996488704](https://twitter.com/sama/status/571733273996488704)

<comment><USER14> I'd really like to be positive about it, because there's an interesting concept hiding inside, but... They neither let me play with it, not address the very basically questions I'd ask. It's purely marketing material for a product at this point.

They talk for example about all the great save-is-deploy things and first- class feature flags and I'm still waiting to know how do I not destroy the production database with one typo and how does staging isolation work in this environment. And how do you revert changes? Again, feature flips they talk about are not it.

<comment><USER8> Founder here. This is fair. Dark is still quite early, and while we're talking about it, it's currently got a lot of sharp and ugly parts that we want to tidy up before we go public.

Happy to answer questions on it though - I answered tons of questions about it in the last HN thread.

Some specifics around your questions:

\- it would take more than a type to destroy the production DB. You'd need to type DB::deleteAll, then run it (which you'll need to do as an explicit action, either click the "run this function" button, or enable the feature flag to users). We'll eventually have backups so you can undo, but we don't yet.

\- staging isolation: there aren't infra questions here since we run the infra. But we'll probably allow DB clones so you can test this sort of thing.

\- reverting: That depends on exactly when you want to revert. If you've made a new flag and you want to not do that anymore, just change the flag condition to "false". You can then cancel the flag, or iterate on it. If you instead want to go back to a previous point in time, we've saved every version and you'll be able to pick from them.

<comment><USER14> Thank you for answering the questions!

With the staging/deletion, I meant a scenario like this: I'm working on some feature which deletes an item I own. But in a delete condition I put "or" instead of "and" (in a non-obvious place) and the function will delete all records instead when it's run.

In the current development model, this will be caught by:

\- me testing it locally (then fixing it and reloading test db)

\- maybe reviews

\- potentially CI/CD

But with what I understand about Dark, this will be close to auto-published on save, and the first person to try the code will delete all entries from a live table/collection.

Backups are ok, but not a solution in this case (you can't just roll back money transactions for example), and the downtime is not great. What system in Dark prevents this from happening in the first place?

<comment><USER8> > this will be close to auto-published on save, and the first person to try > the code will delete all entries from a live table/collection.

Ah, that's not how it works. I think you're thinking that you edit code in your editor and then there's this super dangerous deploy. That's not it at all.

When you make new code you open a feature flag. The feature flag doesn't run until you're ready to run it. We haven't dealt with the delicate case, but I'm imagining that we'll let you put a clone of the DB in so that you can test it.

And you can have code reviews and tests and so on while the feature flag is open. Think of it like a branch.

</comment></comment></comment></comment></comment><comment><USER15> I'm getting serious "Building Dropbox is trivial with with curlftpfs, SVN and CVS"[0] vibes from this thread.

Sure, all it provides is already technically possible with what exists - <USER2> what if the 10% they shave off turns out to be the crucial 10% that carve out a completely new area in programming? Maybe having a fully integrated development experience actually is the "retrospectively obvious" missing thing...

That said, their exclusivity-first approach whose first step essentially is full and complete vendor lock-in makes me skeptical too. I personally don't think they'll be too successful, as the model they're proposing is both uninviting to newcomers and fraught with sustainability perils for any serious long-term project. And that's just from a business perspective, I can't overstate how important I consider open technologies to be.

But I can't get rid of the "future of programming" tingling, which a few people here have alluded to as well. The "open-decentralized-interoperable" bazaar and the "monolithic-integrated" cathedral conflict is as old as time. And while zero-friction infrastructure is a nice selling point, I'm personally more interested in what's allowed by having the language, editor, and apparently the entire ecosystem be developed hand-in-hand from the first step - a lot of fancier features (smart code completion, thorough static analysis, code exploration, automatic diagramming, proper e2e testing) is hard specifically because it needs to built on top of what already exists.

Having a garden with walls this high might actually bring a lot of surprises.

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

<comment><USER16> While I agree with a lot of what you said I'd like to point out that Dropbox's initial customer was the common person, a non-tech savvy person who didn't want to carry USB drive around. Dark's customer base are developers in this thread, likely to be early adopters. That's my sense at least.

</comment></comment><comment><USER17> Radical approach - they flip the whole thing upside down. The biggest challange is not new language or ide per-se imho - but detachment from git, this has implications ie. it seems open-source hostile (you can't use it for open-source code, or am I wrong?); what about libraries?

Technically very interesting.

Practically I'm not sure it'll fly, at any complexity project development means in big part playing around locally before pushing ideas up. On dark platform the code seems to be in compiled = deployed state only, or am I wrong? What about documentation, how is testing done, benchmarking, integration tests, if the system goes crazy, is there a way to actually stop it? What about recovery from backups? Reverting to past history code? After reverting is the new code still available so it can be fixed before next deployment?

The scope they're claiming is gigantic, they must be taking compromises somewhere. There's no way is all unicorns and rainbows.

However if they manage to execute it well, the potential is huge - they can create marketplace for libraries/services, they can become appstore+github+aws in one for execution-ready solutions (libraries, services etc), which could be huge.

Wolfram does something similar. Salesforce as well. Dark seems similar but for webdev, it's like serverless/lambda v10.

<comment><USER18> detachment from git? really?

this strikes me to be odd: why is a SCM all that important? even more important than a language and the ecosystem or as a vendor login already mentioned by several posters?

<comment><USER19> > why is a SCM all that important?

It's a central integration point for many workflows these days: code review, CI/CD, issue tracking, code quality metrics etc.

If you don't use a standard SCM, you'll have to either do without those tools, or build an integration yourself.

</comment></comment></comment><comment><USER20> I am doubtful. My view of the future of software engineering is that developers will be better equipped to handle _more_ complexity, not _less_. And we all know what happens when there's black boxes. Not to mention you're locked in to a particular editor and language.

Imagine this, but with any editor or language of your liking, and the option to go deeper into the machine if things go awry. Wait, isn't that how things are right now?

> Infrastructure is time consuming and difficult, especially as services start > to scale.

It doesn't have to be, and it's particularly easy when you're starting out. Most of the time it's just premature optimization. When services start to scale, maybe you can invest a little more effort into this area, too, so why use Dark?

</comment><comment><USER21> This would have appealed to me before building a rather large side project with Google Cloud's proprietary Firestore database. There are loads of drawbacks that slowly become apparent the more I build and the deeper I dig myself into that hole. I loved how quickly I was able to get something up and running, and was super excited about it at first. But as I've had to add more and more features and turn it into a real project, being limited to only the tools provided by the vendor has become a real drag. Migration, testing, debugging, is all so much more of a pain. Can't even run my application locally without an internet connection. On top of all of that, there may be pricing hikes, or the service could go away all together.

With that experience, it would be hard for me to be convinced that something like Dark would be worth the risk. With things like this, you don't always realize the drawbacks until it's too late. Now, for my side project, I'm only really stuck with the database - locking myself into a programming language and even a text editor sounds like a nightmare.

</comment><comment><USER22> In high school, I think I worked for a company that has prior art on deployless software. We wrote php and perl directly on the prod server with vi through putty. No deploy necessary!

What's old is new again I guess.

<comment><USER23> Well, with compiled languages and multiple servers it does get a bit more complex.

But yes, these online editor products have been created before and afaik they rarely get significant traction. Yet, even a small user base might make it profitable, so it _does_ make sense, and hence these companies.

<comment><USER24> > Well, with compiled languages and multiple servers it does get a bit more > complex.

Compiling (and basically anything) can be done as a cgi script ([https://github.com/RhysU/c99sh](https://github.com/RhysU/c99sh)), I bet you could go a long way with that on a network drive or with an rsync daemon.

</comment></comment></comment><comment><USER25> This reminds me a lot of the Salesforce Apex platform where the language, runtime, datamodel, hosting and all infra is part of one package.

But Salesforce has a very specific niche, this seems to be for general purpose web dev and I'm pretty sure it will be a hard time getting people to switch.

<comment><USER26> Isn't the platform part of Salesforce also pitched as a general purpose application development platform? (force.com or something).

Microsoft used to pitch their CRM in the same way as an "XRM".

</comment></comment><comment><USER27> I'm very excited about this idea and have even asked for an early access invite.

These days I don't care about being in full control of my back-end stack - <USER3> just want to build something and ship it with least hassle as possible. I don't want to deal with provisioning, infra as code, containers, orchestration, message queues, load balancing, autoscaling, build configs and sundry.

I just need a statically typed functional language in which I can do that, which Dark is - it seems to have an Elm/OCaml inspired language.

Being fully tied to their platform with no alternative to migrate away to is the least pleasant aspect of the product as it stands today. But the product isn't even public yet - it is a difficult problem space that is badly in need of innovation and simplification - and many things are yet to be figured out. I'd be charitable to that aspect and see what as an industry we can learn from what Dark is doing.

<comment><USER28> > I just need a statically typed functional language in which I can do that, > which Dark is - it seems to have an Elm/OCaml inspired language.

Is there some information about the language somewhere? I don't seem to find any information from the site.

<comment><USER27> [https://medium.com/darklang/real-problems-with-functional- la...](https://medium.com/darklang/real-problems-with-functional-languages- efe668c5264a)

</comment></comment></comment><comment><USER29> The page for the language is here - [https://darklang.com/](https://darklang.com/) but sadly no technical details appear to be publicly available at this time.

<comment><USER30> I'm not convinced. The authors cite sources of complexity that are mostly domain-specific artifacts of web development, yet make pretty broad claims about a fundamental advancement in language design. Maybe the authors have some insight about these pain points, but it certainly doesn't seem necessary to create a whole new language to solve them, especially as frameworks such as gRPC have already (at least partially) solved one of these supposed fundamental issues without replacing the base programming language.

<comment><USER29> I am not convinced either. Getting a language off the ground is a 10 year affair, don't think its possible for a funded company to bring up a new language unless they are targeting some niche where full scale programmability is not a requirement.

</comment></comment></comment><comment><USER31> After the Parse.com fiasco I am not touching a high-vendor lock-in BaaS ever again.

<comment><USER32> I'm admittedly biased (early Parse employee, but not there by shutdown). Which part was a "fiasco"? As far as turndowns go I thought it was pretty damned fair: one year notice, a live data migration pipeline to self-hosted mongo, and an open source server implementation with a free license. Facebook even paid employees to continue working on the OSS components for a while till the community became so abusive that they moved elsewhere. The only thing I think could have been smoother is if Parse appIds were indicated by subdomain rather than header, which would have allowed switching over without client code changes and minimal cost to Facebook.

And does Dark even have the same sort of risk? It says your code runs on Google Cloud, which sounds like you get to walk away with your own backend if they shut down. Parse considered AWS an implementation detail, not a feature.

<comment><USER31> The fiasco was not on Parse's end but it was ours for locking ourselves into their platform.

The sunset window was indeed fair and as you described they provided a clear migration path to self-hosted mongo and eventually the open source server.

The main problem was the vendor lock-in where our code base was completely tied to their platform and the migration which cost a lot of developer/ops time was forced upon us. Instead of improving our product we had to spend our time and money on the migration to the open source server that was still in its infancy.

After running the open source Parse server for a while which was not without its issues we decided to rewrite the product in Java/Spring/Postgres and now we are free from the lock-in. If AWS decides to quit we can move it over to Azure or GCP without too much problems.

My original comment was not a stab at Parse but a word of warning for choosing BaaS services. Parse allowed us to ship an MVP that turned into a V1 in very little time. But that productivity came with a hidden cost. A cost that nearly killed the company.

Currently there is very little known about the Dark platform and language. From what I see it looks a lot like a next-generation Parse or Firebase and I am very cautious about adopting something like that again.

<comment><USER33> However, there's always a new generation of developers who will inevitably make the same mistake that you (and I) did.

</comment></comment></comment></comment><comment><USER34> I've used Dark for the backend of a mobile app (> 20k installs) during the beta, and it has been an incredible experience. Something like 30 lines of code do it all.

Dark is a game changer in my opinion for getting a prototype online as quickly as possible, or a lightweight backend - and I imagine it can and will support much more.

</comment><comment><USER35> This seems misguided to me. How do you get people into an ecosystem like this that is totally isolated.

If I'm a startup am I going to choose a language that has no developer base and no experienced devs and no ecosystem, without git, that's closed source so I can avoid hiring some devops manpower?

It seems like only a company with a massive builtin captive audience could pull this off. This makes it feel like they are doing this to be acquired which makes the whole thing even less appealing.

</comment><comment><USER36> Should probably replace with the first-party article: [https://medium.com/darklang/dark-announces-3-5m-in-seed- fina...](https://medium.com/darklang/dark-announces-3-5m-in-seed- financing-d64af8a58c1d)

<comment><USER37> That site also has the benefit that I don't have to sign my personal info over to oath and their thousands of partners to read it.

<comment><USER11> I use outline.com to avoid that: [https://outline.com/q7MMgC](https://outline.com/q7MMgC)

</comment></comment></comment><comment><USER25> The marketing reminds me of the famo.us launch.

"Everything completely different and proprietary and we don't have any actual real life examples"

<comment><USER38> For some reason I get the same vibe. Let's hope they learned from the famo.us case (badumtsss).

</comment></comment><comment><USER39> It sounds pretty cool until the point where you read something like: "Deployment is risky because you've only tested on your own machine, and now you need to run the same code on many different machines, to serve (millions of) users." Which makes it seem like they don't even know about the existence of Docker; making me doubt most of what they'll try to sell us.

<comment><USER8> Founder of Dark here. Here's a thing I wrote about docker before, that led me to create Dark. [https://circleci.com/blog/its-the- future/](https://circleci.com/blog/its-the-future/)

<comment><USER39> Don't get me wrong, I understand where you're coming from and what your goals are; it'll be grand if Dark can deliver on its promises. I just don't understand why that particular statement on deployment had to be included, as it makes it sound like you're solving a problem with an existing solution.

<comment><USER8> Unfortunately when you do press, you're at the mercy of whatever gets quoted and sometimes things that are kinda irrelevant get picked up. That's definitely not the thing we wanted as the lead. Our blog post on it was different: [https://medium.com/darklang/dark-announces-3-5m-in-seed- fina...](https://medium.com/darklang/dark-announces-3-5m-in-seed- financing-d64af8a58c1d)

<comment><USER39> That's a fair point. Regardless of my current impression, I'll have to try it out first hand in order to form a proper opinion, so looking forward to the public release. Good luck!

<comment><USER8> Thanks!

</comment></comment></comment></comment></comment></comment><comment><USER40> For the last 10 years I've been working mostly on CI and CD automation for a few projects that as part of their offering tried to automate the deployment for their clients.

In general when you try to simplify a process you increase the level of abstraction which leads to additional complexity in terms of customization and integration with third party systems and tools. Then you decide that it is a good idea to offer integration with the third party systems and tools and you increase the abstraction even more which increases the complexity even more. Also in the end you wonder if you are in the CD tools business or you are offering your core product.

It is much more productive to develop the product in mind with the tools for deployment that are already available. Unless you want to have a product and a "Services" division that configures and operates your product for the clients...

<comment><USER41> Agreed. You have to develop such that your product survives whatever is fashionable today in any case. As Joel Spolsky pointed out at some point, your architecture is not the framework you picked.

On the other hand, CD/CI needs to be an enabler and in small startup there is only so much time you can dedicate to it. Any change on this front tends to be disruptive and suck up non trivial amounts of development time. So keep it simple. Follow the principle of the least amount of surprise (for new team members if you hire them). And keep it reasonable. You are going to cut corners here one way or another. Don't obsess about that.

The Dark people seems to want you to buy into their entire stack (editor, language, saas platform, etc.). That sounds like a lot of risky unproven technology to me. Maybe use something more mainstream like heroku?

</comment></comment><comment><USER42> I've been coding since I was a kid, for about 33 years. I actually think they are right about all of this stuff.

Including the part about combining everything together into a holistic solution.

It sounds like a terrific idea. Unfortunately most people seem to hate good ideas. Especially if they represent a significant change from the status quo.

And programmers are afraid to touch anything that's "easy" or moves away from colorful text representing complex obscure systems -- because sadly that is actually the only definition of programming that has stuck. And if there isn't enough of that stuff, programmers are worried they may be mistaken for users.

But maybe even though its a structured editor that makes things easier, it will still look like code and "count" psychologically as programming.

Anyway maybe it will actually become popular. Who knows. Good luck.

<comment><USER43> Did you had any experience with "low code" platforms? It is all easy until you hit that one case where it stops beeing easy. The same with image oriented languages. Maybe a lot of projects will profit from such solution, but for such projects that can be done "low code" you don't need developers. There has to be culture shift. If you need developers to operate your "low code", "low infrastructure", as business person you are doing something wrong.

</comment></comment><comment><USER44> I think that's the future. Perhaps not exactly Dark itself since we know nothing about it but a toolset that integrates all moving parts from current computation and information engineering and sets them in a well coupled system. Reinvent the wheel at higher levels.

</comment><comment><USER45> Previous discussions with answers from the founder: [https://news.ycombinator.com/item?id=19274083](https://news.ycombinator.com/item?id=19274083) [https://news.ycombinator.com/item?id=20394166](https://news.ycombinator.com/item?id=20394166)

From my point of view I don't think I could inextricably bind my projects to a third party without any recourse in case something on their side changes. Deployment is not really a big deal nowadays, unless you work at a huge scale. But if you are working at that scale I don't really think that you are eager to commit yourself completely to a small startup.

</comment><comment><USER46> I have a hunch that Dark won't generalise well. It might be good for making simple data-backed web applications. But a business of any nontrivial size has more than just simple data-backed web applications.

Do you use Dark for part of your business, and traditional tech for the rest, in which case you now have the problem of integrating your traditional stuff with Dark's black-box infrastructure?

Or do you build an MVP on Dark, then migrate on to traditional tech when you grow, in which case you now have the problem of migrating your entire business?

Or do you bet that Dark will pull more rabbits out of their hat, and you won't need to migrate?

<comment><USER32> Or do you use micro service architectures where some of your services (eg ML training) runs on dedicated/specialized hardware and traditional event/request based business logic can be written more quickly and only moved to Dark incrementally?

</comment></comment><comment><USER47> I mean I guess. Salesforce did it with Apex and Wolfram did it with Wolframlang or whatever Steve is calling it these days. But I feel like this is a solution in search of a problem. The issue isn't complexity or even accidental complexity. It's that businesses usually have many competing and often conflicting needs. I can already hear the angry snort when I go to the head DBA and ask if I can use some new hosted product to replace our on prem data warehouse. It'll never happen. And it's not even an "old school" thing. We just have a variety of reasons why it's a bad solution. So now we talk about setting up small web apps hosted in Dark's cloud. How is it any better than what we have hosted in Amazon, Google, and Azure where we also have the ability to at any minute tap in to a huge market of developers? I guess then we look at this for new projects that aren't interfacing with production stuff? In that case I guess it's an interesting experiment. But the reality is that most corporate things (from my experience anyway) have an if it ain't broke don't fix it mentality and with good (often painfully learned) reasons. I'm not debating the values of this (it's hard to since their entire site is marketing buzzwords) but I'm saying it doesn't seem on the face of it to be a realistic problem solver. I'm very likely wrong but that's how it feels to me.

</comment><comment><USER48> They really need a good bottom-up example showing what Dark is and why it is different from ssh-ing into a production server and fiddle with some php- scripts.

They write about feature flags, non-text code and a fully integrated environment. So what they are trying to do is different however these ideas has been around for some time (Smalltalk/Self/some databases) but have been not been adapted by the industry of practical software development.

Probably because the implementation was never really good enough.

</comment><comment><USER49> I don't get it. I tried to find out anything about what Dark is, how it works, or what it looks like and found almost nothing. They make claims like "holistic programming language" but don't show me what they mean. The What is Dark[1] blog post makes a lot of claims, but I've seen these claims made many times and they rarely live up to the hype. They don't show me how they plan to meet these claims or what it looks like. Finally, their marketing focus is on deployment, but honestly, deployment really has never been the biggest pain point for me. Sure, it can be a headache, but its nowhere near as much work as actually writing the applications themselves. I'm not convinced.

[1] [https://medium.com/darklang/the-design-of- dark-59f5d38e52d2](https://medium.com/darklang/the-design-of- dark-59f5d38e52d2)

</comment><comment><USER13> This is hardly "emerging from stealth". This was a blog post from February! [https://medium.com/darklang/the-design-of- dark-59f5d38e52d2](https://medium.com/darklang/the-design-of- dark-59f5d38e52d2)

<comment><USER50> Okay good. I was feeling so confused because I could have sworn I saw them posting like a year ago about paying a few early startups to dogfood the Dark platform as it was being developed.

</comment></comment><comment><USER51> "Emerges" my foot, this is a marketing rollout. Code or GTFO

</comment><comment><USER46> Looks like one thing the infrastructure doesn't automate is using the right SSL certificate:

[https://hellobirb.com/](https://hellobirb.com/)

(that company is an early adopter mentioned in [https://medium.com/darklang/dark-announces-3-5m-in-seed- fina...](https://medium.com/darklang/dark-announces-3-5m-in-seed- financing-d64af8a58c1d) )

<comment><USER52> SSL certificate automation is the hardest part of any stack.

<comment><USER11> Depending on how you approach it, it can be completely automated: [https://github.com/Neilpang/acme.sh](https://github.com/Neilpang/acme.sh)

</comment></comment></comment><comment><USER53> I now almost nothing about Dark, but I don't understand why it is necessary to do this with a new language and a new editor.

<comment><USER46> I remember doing this in Smalltalk in about 2010. Multiple editing one image, which was running live!

<comment><USER44> besides second player gaming emotions, how did it turn out? was it value there aside of pair programming?

<comment><USER46> I only tried it once, and the technology was pretty flaky at the time. I don't think it really went anywhere.

The focus was on the fact that you could have multiple people editing a single codebase at once, rather than on doing it in production. Indeed, you wouldn't have to do it in production, you could work on a shared development image. That was definitely a very interesting sensation, having a whole team working in a single space; like pairing but much more so. Lots of calling out to other programmers to ask them what they thought, or to suggest something. You could all work on parts of an idea at once, so you could try things out quickly. But there was so much overhead in making sure you didn't tread on each others' toes.

This doesn't seem to be the emphasis in Dark at all. In fact, i don't know what Dark's story about collaboration is. It seems to be much more about the instant deployment, and all sorts of sci-fi tooling to make that safe.

</comment></comment></comment></comment><comment><USER32> One question/unsolicited advice: the articles frequently mention "feature flags," but these will cause simultaneous rollout in prod without any real testing or canary.

It seems like an experiment framework (eg whitelisted customers or IP addresses for alpha testing and percent rollouts) is a min bar for any reasonable implementation in Dark.

<comment><USER8> I think that what you're calling an experiment framework is what we call feature flags.

<comment><USER32> It's good your feature flags have the necessary...features. The same word is often used for global bools; I wish there was a better word (eg "experiment" or "experiment flags") or documentation to brag that you're doing more than simple flags.

I'm also curious what kind of infrastructure you use to affinitize the rollout to particular customers. I'm used to that being coupled to user or device IDs, which I don't see as a coupled feature of your stack.

</comment></comment></comment><comment><USER54> I've only seen self pleasure articles about this company.

Has anyone seen what the language or editor looks like?

</comment><comment><USER55> Is there a code sample I can read? Seems like this will all hinge on this new language.

</comment><comment><USER56> I said this last time I read about it and I'll say it again because all I keep reading are puff-pieces with nothing to back it up, it sounds like a convoluted version of Geocities, funded by a seed round from Russ Hanneman.

</comment><comment><USER8> Cofounder/CTO here. Sorry this went up when I was sleeping, so I missed the discussion. I'll answer some things through the threads but if you have any questions for me I'm here.

</comment><comment><USER57> similar things have been possible for years with C# in visual studio where you can deploy to azure with the click of a single button if you want to.

</comment><comment><USER58> How do they make money?

<comment><USER8> Dark provides the infra, so you pay us for how much compute, storage and traffic you have (pricing is planned to be cheap, think close to AWS prices)

</comment></comment><comment><USER59> So is it a 'deployless' software model, in a 'serverless' environment¿

sorry i could not resist.

</comment><comment><USER60> So it's a lame version of dot net / Azure?

<comment><USER32> Per another article, the editor doesn't even allow syntax errors. Seems like they have a tight pipeline built around AST manipulation, which is actually novel. I'm not sure I understand why that took a new language though.

Disallowing some side-effects? Ensuring all valid code follows their rules? Avoiding being dragged along by other languages authors' changes? Something to do with the deployment pipeline, which implies a runtime requirement?

</comment></comment><comment><USER61> Personally I'd be surprised if this startup is around in five years

<comment><USER46> Right. It sounds like a fun thing to build. But i'd love to read an honest explanation from an investor of why they funded it.

Dark raised 3.5 million USD from eight funds, which is under half a million each; maybe that amount is so small that a VC will invest it just for fun?

<comment><USER62> The founders are well-enough connected to get this sorta funding...

<comment><USER46> Right, and Paul Biggar founded CircleCI before this, which has been pretty successful!</comment></comment></comment></comment>


Bot Mafias Have Wreaked Havoc in World of Warcraft Classic - <AUTHOR> https://www.wired.com/story/world-of-warcraft-classic-russian-bots/ <comment><USER2> This was also common in retail prior to adding the ability to buy gold from Blizzard.</comment>


Most StartSSL certs will stay compromised - <AUTHOR> https://bugzilla.mozilla.org/show_bug.cgi?id=994033 <comment><USER2> Pathological customers: when you give them free stuff, they will demand more free stuff, and if you refuse them more free stuff, they will do their darndest to destroy your business.

Meanwhile, look at all the nonsense that e.g. GoDaddy (who also charges for revocations) is not getting right now. Because the folks with altered understandings of reality got scared away by the $20 or whatever it costs on year 1, and are plaguing StartSSL instead.

<comment><USER3> > Pathological customers: when you give them free stuff, they will demand more > free stuff, and if you refuse them more free stuff, they will do their > darndest to destroy your business.

I guess you caught me. On the other hand, at the time I started using StartSSL, the cheapest non-free certificate provider I could find charged something like €70 a year, which was more than it was worth to me. Just two days ago I happened to look for cheap certificates again and found one for €9, and I'd totally pay that as long as my real name can stay anonymous (like now with StartSSL, my name isn't included in the certificate).

So it also has much to do with how much you charge. Free is a special price and may make people ask for unreasonable things, but if the choice is between nothing or more than it was worth, that choice is very easy. Then when shit hits then fan...

</comment></comment><comment><USER4> As a free SSL provider I think this is entirely valid for them to charge for revocations. Plus, it's entirely possible that not all people using certificates from StartSSL are using OpenSSL.

It's the cert owner's prerogative to ensure their certificate is properly secured. There's no reason for debian/mozilla to remove StartSSL from their CA lists. If you have StartSSL and you used OpenSSL 1.01f or another vulnerable version, pay the $25 and move on-- it's cheaper than if you used godaddy.

<comment><USER5> It is totally valid for you to be a jerk, and then it is totally valid for other people to call you out on being a jerk.

Yes, maintaining a revocation list costs them time and money. But this is a Big Deal. Extenuating circumstances. They have a social responsibility here, and they're failing at it.

<comment><USER6> They do not have a social responsibility.

It is totally valid for people to call them out for not going above and beyond, but that doesn't mean Mozilla/Debian/etc should be popping them out of CAs.

The mob is welcome to mob, but Mozilla and Debian shouldn't be making decisions based on the whims of the mob.

<comment><USER5> If you can't trust the certificates they produce, then they should be removed. And there will be a lot of valid-but-dangerous certs in the wild from them.

<comment><USER7> You _can_ trust the certificates they produce. It's only users who were running exploitable OpenSSL who's certs are at risk through no fault of StartSSL. There will be many perfectly safe certificates from other customers affected if the root trust is revoked.

<comment><USER5> You can trust some of the certificates the produce, but you don't know which one. A responsible person would trust none of them, because you can't know who you can and cannot trust.

</comment></comment></comment></comment></comment></comment><comment><USER8> If it was a StartSSL security leak, then I would expect them to give away revocations for free. But if YOU, the customer, leaked your own private key by running some bad software? That's simply not their fault, nor their problem.

<comment><USER9> StartSSL is actually causing a problem, though.

With a regular CA, you pay upfront, and you can revoke and reissue with no problems. If you trust a CA that does this, you can count on the fact that anybody buying a cert from that CA has the ability to grab a brand new certificate whenever they want until the expiration period.

But with a CA like StartSSL, they give out certificates without guaranteeing that websites using those certificates have the ability to regenerate their certificate. If a website gets compromised, since they haven't paid upfront, you don't know if they will pay to reissue. They might just keep quiet and pretend there was no security breach, instead of doing the proper thing and renewing the certificate. If you know they paid upfront, you can be more sure that they will take advantage of the free renew upon a security breach.

I find this issue to be vaguely similar to the difference between socialist healthcare systems and privatized healthcare systems. If everyone is guaranteed to have healthcare because it must be paid through their taxes, then people are generally healthier since they are encouraged to go to the doctor. But if you must pay a bill whenever you receive healthcare, people might be encouraged to forego treatment or checkups that could catch deadly diseases in an early phase before they become life-threatening. I don't really think this is a good analogy though because the other pros and cons of both healthcare systems don't map well to this problem.

<comment><USER10> StartSSL's denying free cert revocation does not make them untrustworthy from a technical perspective. The onus remains on the site owner to implement their site security properly and pay any fees necessary to do that. So the only issue here is a moral one and whether you believe they have a responsibility to revoke these certificates for free.

I think that given the extenuating circumstances, they probably _should_ revoke the certificates if requested, but I have no right to demand that they do so.

</comment></comment></comment><comment><USER11> Let me see if I have this straight:

        Alice's Lemonade Stand charges $0.25 for a cup of ice-cold lemonade,
        and has a recycling bin that her customers can use for free.

meanwhile, down the street:

        Bob's Lemonade Stand gives out free lemonade,
        and charges $0.25 to use their recycling bin.

The message here is basically "boycott Bob for his anti-recycling business practices", right?

Seems like a distinction without a difference to me.

<comment><USER9> Personally, I think it's more like this:

        Alice's Lemonade Stand charges $0.25 for a cup of lemonade,
        gives out free refills, and will give you a new cup each time.

        Bob's Lemonade Stand gives out free lemonade with free refills,
        and gives you one free paper cup to start with,
        but you must use the same cup each time.
        Bob charges $0.25 to replace a lost, damaged, or dirty cup.

So basically people who go to Bob's Lemonade Stand are incentivized to continue drinking from the same cup even if it's dirty (its integrity is compromised.)

Of course it's not a perfect analogy since certificates eventually expire, but you get the idea.

<comment><USER6> This is akin to saying Amazon Glacier should be boycotted for having a low cost of entry and high cost on the other end.

Their business strategy isn't a secret. If there were a vulnerability found in btrfs and a wave of people had their filesystems go belly up, I'd not expect Amazon to change the price of restorations.

<comment><USER9> The issue here is not about boycotting StartSSL because of their 'vulture- like' business model, it is about whether StartSSL can be trusted by browsers to actually secure connections. It can be argued that StartSSL is not actually providing an acceptable level of security, since the ability to revoke and regenerate a certificate is part of the service that a CA should provide. If StartSSL isn't performing security audits, gives out free certificates like candy, but charges for maintaining security, none of the free certificates are actually known to have any level of security.

There are many websites using StartSSL certificates that could also be using a compromised private key. Should there really be a lock icon in your browser if your connection is not actually secure?

<comment><USER6> StartSSL does provide revocation and regeneration of certificates. They charge for this service, just like other CAs charge for generation of certificates.

I would much rather StartSSL provide free certificates, even knowing that not everyone whose private key was compromised regenerated a certificate, than have StartSSL pulled from trust stores and thus cause fewer future sites to not have SSL because of the associated cost.

<comment><USER9> This is more of a problem with the simplistic trust model that is typically used with X.509 and TLS, rather than a problem with StartSSL. The type of security that you are suggesting is similar to opportunistic encryption or decentralized trust. Self-signed certificates are intended to fill this role, however, it is too difficult for the average user to use self-signed certificates securely, so browsers put up a scary warning to protect users from themselves. If cryptographic concepts could be securely exposed to end- users, then self-signed certificates could be used securely. In that case, StartSSL wouldn't even need to exist. Unfortunately in the current trust model that is being used, StartSSL has to exist to fill the niche for people who just want SSL to work. But because of recent events, this creates a problem in which the all-or-nothing security model essentially requires that StartSSL be blacklisted because of their business model.

<comment><USER12> Keeping in mind that while plain self-signed certs just don't work at all given user-behavior, self-signed certs _plus TACK_ have about the same security level as SSH host keys. If-and-when most browsers have TACK, and most sites use TACK headers, the CA infrastructure will become mostly (though not entirely) irrelevant.

</comment></comment></comment></comment></comment></comment></comment><comment><USER13> As an end-user I couldn't care less about CAs, their business models, and the way they handle revocations. All I care about is that if I see a lock icon in my address bar I can be sure that the page I'm looking at comes from whom I think it comes from.

This is what should be driving Mozilla's decisions, not the moral aspects of charging for revocations.

<comment><USER14> Very well stated. You should consider submitting this to their mailing list discussion on the topic.

</comment></comment><comment><USER15> If someone stole your certs you are basically screwed until they expire. Currently most browsers don't check if certs are revoked.

<comment><USER16> This is a good point that seems to keep being ignored: do revocations even matter? Are browser makers planning on changing their defaults with regard to revocations? Is somebody planning a widespread consumer education campaign regarding revocation? If not, this whole issue seems like a bunch of noise that doesn't have much real impact.

<comment><USER17> For example at Mozilla there are discussions about it, I suspect it's happening for other browsers too:

[https://lists.mozilla.org/listinfo/dev-security- policy](https://lists.mozilla.org/listinfo/dev-security-policy)

<comment><USER16> Any links to specific threads? I don't find anything when searching that list for "revocation" or "revoke", though there seem to be lots of threads about CAs in general, so maybe there's relevant discussion in some of those.

<comment><USER18> [https://groups.google.com/forum/#!searchin/mozilla.dev.secur...](https://groups.google.com/forum/#!searchin/mozilla.dev.security.policy/OCSP/mozilla.dev.security.policy/mwmg2X74vlI/fYEljQnJVN4J) for example (3 years old).

The right keyword to search for is OCSP, because CRLs are completely impractical in the browser.

But then we have the issue that OCSP is a pretty retarded protocol. OCSP stapling helps with some issues, but there is still the issue that it doesn't really check if a certificate is valid, but whether a certificate bearing the given serial number is valid. Which didn't help AT ALL when using MD5 collisions people managed to create multiple certificates under the same serial number.

</comment></comment></comment></comment></comment><comment><USER19> Are there any cert providers who have particularly solid reputations?

I get basic certs via my domain provider Gandi, they run ~$17 year (12 euros), or $160 for wildcard which seems steep.

<comment><USER20> Comodo PositiveSSL for $9 / year and $99 for wildcard.

Multi-domain (100 domains or subdomains) for $30.

[https://www.namecheap.com/security/ssl- certificates/comodo.a...](https://www.namecheap.com/security/ssl- certificates/comodo.aspx)

<comment><USER21> Comodo Positive SSL for $9/Year offered by namecheap is really very much cheap in price, but there is one more SSL certificate vendor "CheapSSLSecurity" that offers comodo Positive SSL at only $5.99/Year and if you are purchasing it for 5 year then the price is most cheapest at $4.80.

For Wildcard SSL Certificate I've found that "CheapSSLSecurity" offers it at $72.95/Year and $58.36 for 5 Year.

I bet no one can beat CheapSSLSecurity's price.

</comment></comment></comment><comment><USER22> Now this seems like something that StartSSL would want to be in front of rather than risk everything by having compromised certs out there with their name on them. I would think that kind of behavior would put their CA status at risk...

<comment><USER23> Their CA status is not at risk, was never at risk and will not be at risk in the future. Mozilla has made their stance clear that once you are in, you will never be removed (unless you were compromised, at which point they'll happily add your new CA).

I'll certainly not claim that we can magically make TLS work by starting to enforce the requirements we put on CAs. But we should call Mozilla out for their _strongly worded letters_ and other nonsense to get some momentum for better solutions. The first step is admitting you have a problem.

<comment><USER24> Incorrect. DigiNotar[1] was permanently removed.

Quoting Mozilla[2]: _" This is not a temporary suspension, it is a complete removal from our trusted root program."_

[1]: [https://en.wikipedia.org/wiki/DigiNotar#Issuance_of_fraudule...](https://en.wikipedia.org/wiki/DigiNotar#Issuance_of_fraudulent_certificates)

[2]: [https://blog.mozilla.org/security/2011/09/02/diginotar- remov...](https://blog.mozilla.org/security/2011/09/02/diginotar-removal- follow-up/)

<comment><USER23> They were removed for being compromised and went bankrupt before trying again. I don't see how that invalidates what I said.

Meanwhile, CAs that have issued CA=yes certs remain, but you know, Mozilla wrote them a letter reminding them on security best practices.

<comment><USER24> True that they went bankrupt, but they filed on Sep 20th 2011, and the Mozilla decision to _permanently_ remove them was a week prior or at least on Sep 2nd 2011; thus _" unless you were compromised, at which point they'll happily add your new CA"_ is not correct.

EDIT: To clearify, this is the phrase that we seem to be arguing about: _Complete revocation of trust is a decision we treat with careful consideration, and employ as a last resort._ (from the Mozilla Security Blog link above).

They were effectively out in the cold, not "in once you're in" after the incident.

</comment></comment></comment></comment></comment><comment><USER25> StartSSL revoked one of my certs on request the night Heartbleed came out. I mentioned heartbleed in the form.

However, that was a $24.90 gamble.. They could just has easily billed me. Especially if you have a lot of different certs, that gamble may not be worth it.

Also, I'm a paying customer, having gone through their process to get a wildcard cert. A free customer may have different results.

And then, browsers don't check SSL cert revocations, and the infrastructure to check reovocations is apparently broken too. So this is a gamble with not much of a payoff.

</comment><comment> mike-cardwell They should have taken this as a marketting opportunity and offered up free revocations for a week.

<comment><USER6> I think that would have been a successful PR move, but deciding if they're rather have the money or goodwill is their choice to make. They told people upfront what the costs were, I don't fault them for following through with that.

</comment></comment><comment><USER26> Red Hat Enterprise Linux Server release 5.6 is still supported and ships with OpenSSL 0.9.8e which is not vulnerable. I am sure there are other examples as well. If I had a StartSSL certificate and the browsers started to remove support of them or warn that my site has a StartSSL certificate signed before a certain date and cant be trusted I would be really pissed.

I have always felt there was conflict between system administrators wanting proven and stable versus developers wanting bleeding edge. I have given up the fight when it comes to web development and use Ubuntu 12.04LTS which still is not bleeding edge enough for most of my dev's. For infrastructure components outside of web development though I dont think its a safe assumption that people are on a vulnerable version.

This is a prime example of why I would never give anything away free. Unrelated to SSL certificates; I rather throw out my old equipment than give it away since the people I give it too will never be happy and don't understand its free for a reason and demand support. The fact that you cant afford something better does not give you rights to it.

</comment><comment><USER27> I'm worried that StartSSL free certs will stop being trusted. I run a service (tny.im) where HTTPS is not essential, but I like to provide it, to secure logins if not for anything else. However, I make little to no money from that website, and so I rather not invest much money in it. By the price SSL certs go, if StartSSL became untrusted, I'd have no choice but remove SSL support, or issue my own certificate which is as bad as not having HTTPS.

StartSSL plays an important role in ensuring that all websites, no matter how small, can provide https access. I recommend it to people that are just launching a service; their reaction often is like "SSL? You know how much that costs? I can barely pay for the server!" but they happily go through the trouble of installing a StartSSL cert when they understand that it will only cost them the effort. Without StartSSL these people would never implement https, if for some reason they didn't want to spend money with their project as is often the case with things done in their spare time.

Personally this is even more disgusting, because I know for sure that my certificate has not been compromised: two days ago my service was hosted on a server with OpenSSL 0.9.8, and today I was forced to migrate to a new server due to issues unrelated to Heartbleed, and the certificate was not installed before updating OpenSSL to a patched version. And as some users have said, other people may be using StartSSL free certs on systems that don't even use OpenSSL.

There's also something we should not forget: free StartSSL certificates are only valid for one year. That means that any cert will only be compromised for, at most, a year. My cert will expire in June, and then I'll be able to issue a new one, which (even if I wasn't sure the current one isn't) definitely isn't compromised.

<comment><USER28> You can't afford $20 a year for a cert? Drink a few less coffees during the year.

<comment><USER27> Things add up, you know... $20 for a cert, plus $10 for a domain, and not even taking into account the server, it's $30. Now imagine you have five or six side-projects, you may not be willing to spend $150 per year to maintain them, especially when you get little to nothing in return.

It's not like every website must have a profitable business plan just to be online and secure...

<comment><USER29> That's still $2.50/per month and even less after a write off.

Multiply that by 6 projects and it will be $15 bucks per month.

<comment><USER30> And in case one's living in a third-world country when their income is, say, $600/mo, I think $15/mo is a bit pricey.

</comment></comment></comment></comment></comment><comment><USER31> Is there any actual data anywhere (ANYWHERE) that suggests this is the case? Or statistically more the case than any other CA with a more traditional payment model?

Or is this hand wringing about the stupid people who got the free certificate from the stupid company that likes to give away free certificates but under normal circumstances they might actually charge people for some other part of the service that almost no one ever uses?

</comment><comment><USER32> What are good alternatives to StartSSL? Either free or moderately priced

<comment><USER33> I've been using PositiveSSL. I am paying less than $10 a year for a basic cert, revocation is free.

I don't know anyone else who uses it, but there's nothing not to like so far, unless you are the sort who expects to pay nothing at all for your certs.

<comment><USER21> Today I was searching for PositiveSSL Certificate for my website.

I Googled and found many online store offers PositiveSSL Certificate, but there were major difference on price. I've found some stores offers PositiveSSL at $49/Year, $19.95/Year, $12/Year, $9/Year & $5.99/Year.

I want that PositiveSSL certificate for 5 Years. SO I've bought it from CheapSSLSEcurity at only $4.80/Year. I loved their service. The certificate was issued minute and its now live on my website.

Thanks and Regards Paul Burke

</comment></comment></comment><comment><USER20> How long would it take their staff to revoke a single certificate?

$25 seems expensive for something that can't take more than 5 minutes per certificate, unless there is more to it than I'm aware of.

I guess it doesn't really matter to them if they lose several free customers. [https://twitter.com/startssl/status/453631038883758080](https://twitter.com/startssl/status/453631038883758080)

They're probably making a ton of money from this, in the long run I'm not sure it'll be worth it though.

<comment><USER34> 5 minutes of their employees' time probably cost more than that. And of course it would be silly for a business like this to charge for cost instead of value.

<comment><USER20> Automate it and charge $1.

</comment></comment></comment><comment><USER35> Shouldn't this post be titled: Most StartSSL certs will stay compromised because their customers are too cheap to pay to fix them?

<comment><USER30> Right, but...

I have about 30 certificates from StartSSL. Four second-level domains, and best security practices recommended having a separate key per service, so web server has its own keys, so is email server, XMPP and so on. The idea was that if one's compromised - others would hopefully remain safe.

Call me names, but I'm not going to shell out $750.</comment></comment>


Easter Egg Hidden in VMWare Fusion and Workstation - <AUTHOR> http://www.misc.name/#/pride-easter-egg/ <comment><USER2> Am I the only one not amused by easter eggs in software? It's code that I don't know about doing stuff that I don't know about. More code means more chances for bugs, maybe even bugs that results in security vulnerabilities. If the programmer snuck it in without management approval, it may mean code that isn't as thoroughly tested as the rest of the program.

<comment><USER3> A programmer who bothers to put in an Easter egg to me has pride in what they are creating and also gives them more ownership.

So I see it as both an indicator of good work and a positive thing.

Yes, other's believe that Easter eggs are bad I assume you're referring to the famous [http://blogs.msdn.com/b/larryosterman/archive/2005/10/21/483...](http://blogs.msdn.com/b/larryosterman/archive/2005/10/21/483608.aspx)

It has good points but I believe it to be wrong in conclusion, there's lots of real issues to care about before this one.

<comment><USER4> I agree with Easter Eggs in products. That being said another good example of an "Easter Egg gone wrong" was the games in Excel 95 and 97.

Excel 95 had a "Doom"-like 3D game. Excel 97 had a basic flight simulator. These were fun and weren't buggy, but here's the problem:

How much time do you think was lost in classrooms in particular after all the kids discovered there were games they could be playing instead of working? All of the built in Windows games were removed, and Flash/Java weren't installed. But you cannot remove these if you need Excel.

This was a legitimate issue in the 1990s. So much so that the school I attended gave anyone detention caught playing these games during class time(!). Yet every class there would be someone sitting in the corner playing away.

<comment><USER5> I find it hilarious that you're upset with easter eggs in principle because kids were distracted during class. I'm sure all those kids couldn't hack it in the real world because of these awful distractions.

<comment><USER4> > I find it hilarious that you're upset with easter eggs in principle because > kids were distracted during class.

That's exactly the opposite of what I said, I said I liked Easter Eggs in principle but then gave an example of when they went wrong. The first line of my comment was: "I agree with Easter Eggs in products."

Easter Eggs are good, you just really have to consider the impact they're going to have (in terms of perception, usages, and bugs).

</comment></comment></comment></comment></comment><comment><USER6> Is easter eggs in VM a good idea?

Couldn't malware attempt to locate potential easter eggs in order to determine if they are in a honeypot?

<comment><USER7> VMalWare! Yikes!

<comment><USER8> I laughed harder than I should have.

</comment></comment></comment><comment><AUTHOR> "If you'd like to reverse engineer @scanlime's VMWare easter egg, attach a 0-length floppy image after booting and dump /dev/fd0 with dd."

[https://twitter.com/travisgoodspeed/status/50224961576974745...](https://twitter.com/travisgoodspeed/status/502249615769747457)

</comment><comment><USER9> This is just an article linking to an article[1], which itself links to a Google translation of an article written in French[2].

[1][http://www.virtuallyghetto.com/2013/09/vmware-nested- easter-...](http://www.virtuallyghetto.com/2013/09/vmware-nested-easter- egg.html)

[2][http://www.hypervisor.fr/?p=4063](http://www.hypervisor.fr/?p=4063)

<comment><USER10> The French article has a comment by Regis Duschene one of the VMware Fusion developers stating that there is an Easter Egg in the Easter Egg.

The virtualghetto.com article is referring to that second easter egg (i.e. the Pride mode) and telling you how to "unlock" it.

The post linked to here on HN is by M. Elizabeth Scott who created the Pong OS easter egg while at VMware.

A version of the code of the Pong OS can be found here: [http://sourceforge.net/p/vmware- svga/git/ci/master/tree/exam...](http://sourceforge.net/p/vmware- svga/git/ci/master/tree/examples/pong/main.c)

From a cursory look, I don't think it has the Pride mode.

<comment><USER11> There isn't really an explanation anywhere, but the colors that the game changes to in pride-mode look like original Apple logo colors - is that a hat tip?

<comment><USER12> Yes. Multiple meanings.. gay pride, but also pride in our work, and in producing the first product of its kind for Apple machines, and pride in the small team of us that made it happen within VMware.</comment></comment></comment></comment>


Ask HN: What would you build with $100,000 and six months? - <AUTHOR>

A few days ago I asked my Twitter followers what they would build with $100k and six months. I got several dozen interesting responses which I posted to my blog and submitted here. The HN reader response indicated a preference of seeing an Ask HN so here it is. If you are interested you can read the responses from Twitter here: http://blog.abrah.am/2010/10/100k-dollars-and-six-months.html<p>If you had $100,000 and six months to build a web application what would you build? <comment><USER2> I'd like to call it 'FeedHint'. The idea is very simple, you submit your feeds (OPML would be fine) and the algorithm sends back suggestions, in other words, feeds in the same subject &&/|| similar feeds, based on the previous submissions of the users.

</comment><comment><AUTHOR> I would build my YC app which essentially turns real life into a WoW like RPG using social media.</comment>


Gall's law - <AUTHOR> http://en.wikipedia.org/wiki/Gall's_law <comment><USER2> The book that this is taken from is one of my all-time favorites, a quirky classic that deserves to be better known. Underneath its irreverence are quite a few profound insights. (I'd quote a couple but I leant out my copy.)

More here: <http://news.ycombinator.com/item?id=182937>

Edit: oh yeah, the book is [http://www.amazon.com/Systems-Bible-Beginners- Guide-Large/dp...](http://www.amazon.com/Systems-Bible-Beginners-Guide- Large/dp/0961825170)

</comment><comment><USER3> _A complex system that works is invariably found to have evolved from a simple system that worked._

While it's good to grow a system, and I (and many others) practice it and recommend it, I'm not sure about the _invariably_ part.

I'm sure there are exceptions: like the famous space-shuttle software with minimal error rates; or the aircraft control software that has been mechanically verified in some ways (no null-pointer errors I think); or industrial control systems...

But maybe these even systems did have simpler prototypes, which were then enhanced in simple steps? I know I make faster progress when I operate like this. Or perhaps the prototypes were in the form of an algebra (or other abstraction), which developed from simple to complex in small steps. The final translation to code is also a simple step, and the final product only appears to materialize fully-formed.

<comment><USER4> Your examples perhaps don't look far enough back, and assume "system" means only one specific piece. One could just as easily assume that the "system" in the case of the space shuttle begins with flight and rocketry and the transistor and ends with NASA in Houston flinging a few tons of crap, and a couple of humans, into space and then bringing most of it back down again, usually intact. The software in question was made up of many pieces, many of which were proven useful and correct as parts of prior systems, such as the Apollo rocket guidance systems.

However, if we really take it to that extreme, I guess we'd end up with every "system" starting with fire and the wheel. So, I think it should perhaps be "Gall's truism", or "Gall's rule of thumb", though it doesn't have quite the same ring to it. It isn't quite provable, but can't really be argued against very effectively, either. And, you know, if you pretend like it's a law, it probably won't have negative consequences, while convincing yourself it is false very likely _will_ have negative consequences.

<comment><USER3> I agree it's useful to assume it's true - also, comfortingly reassuring, that, well, one _has_ to go step by step.

One way to disprove the "law" is to look for instances of "leaps in complexity" beyond mere evolution. The only example I can think of is the leap of intuition that geniuses sometimes have, that give an entirely different view of a problem: e.g. speed of light would appear constant if observers had different time frames; the molecules could be linked in a ring; water is displaced by volume.

But the new perspective is itself very simple in each case (assuming the background) - the leap is in having the insight at all, not in its complexity. These are not leaps in complexity; and therefore not counter-examples to "Gall's Law".

</comment></comment></comment><comment><USER5> Systemantics is one of my favorite books. Here's a brief review/overview:

<http://www.daltonlp.com/view/264>

</comment><comment><USER6> It's pg's recipe all over: spit out a lame version 1, see what turns out to be wrong, improve, iterate.

<comment><USER7> I know what you're saying, but I wouldn't use the term "lame." It seems that Gall's Law is essentially asserting that progressive evolution works, and spontaneous creation doesn't. Yet evolution also means that most participants, be they organic or electronic, _fail_ , in the sense that they don't lead to descendants which carry on their code. Only a tiny fraction of all organisms/software have living/executing progeny today.

The article says Gall noted: "A simple system may or may not work." I'd add: "A simple system that works isn't necessarily any good."</comment></comment>