Show HN: Coffer, when Docker is just too much - <AUTHOR> https://github.com/Max00355/Coffer <comment><USER2> This is actually pretty cool. To answer a question someone might have about "why not just use docker". Docker comes with its own learning curve and concepts. Sometimes all you want to do when developing is have an environment in which you can't screw your main machine up. Think of virtualenv in python if you've used it. This might be the equivalent of running docker run -it ubuntu:latest /bin/bash and then developing inside that container. But wait! what ports do you open up? What directories do you mount? And then suddenly you are in docker world. It feels like coffer is just a way to say "hey create me a sandbox where I can mess up things minimally no matter what I install and mess around with". Not sure what files get mounted. Shall try it out in a bit and see how it goes.

</comment><comment><USER3> in what scenario would docker be too much? it's easy to install, easy to run, and highly documented

"Coffer is a platform for creating isolated filesystem containers. It is intended to be used to create isolated development environments without having to worry about doing any network configuration. Applications that are run in Coffer can be accessed outside of a Coffer environment through localhost without having to do anything more than coffer create <name>. This makes it easy to get environments up and running for those of us who do not need network isolation, and only wish to islolate an app and its dependencies."

easily accessed at localhost:8888

mkdir workdir && docker run --name apache -d -p 8080:80 -v `pwd`/workdir:/var/www apache

easily attach

docker exec -it apache bash</comment>


Acqui-hire Is Just Another Way to Spell Failure - <AUTHOR> http://www.jacquesmattheij.com/acqui-hire-is-just-another-way-to-spell-failure <comment><USER2> I think there's a spectrum of failure, and an acqui-hire is not at the lowest end of the spectrum, not even close. Here are a few ways to fail that are worse than an acqui-hire:

\- Your startup fails and you maxed out your credit cards trying to keep the business/servers afloat and end up ruining your credit

\- Your startup fails and you spent all the money you borrowed from your family/friends to start your company, never make any revenue, then ruin those relationships when you never pay it back

\- Your startup fails and you spend a few months looking for a full-time job

Now contrast those scenarios with this acqui-hire scenario:

\- Your startup has not failed or succeeded yet (it may be on the path to failure or success, too early to tell) and you are offered a nice salary (say $150k) plus a one-time stock grant (say $200-500k of RSUs) or a one-time cash bonus (say $100-200k) to work for a company you respect.

In nearly all these scenarios your startup ceases to exist, or lives on in another form separate from how you envisioned it, but only in the acqui-hire scenario are you quasi-successful. To me, an acqui-hire means that 1) a company noticed your product or service, 2) saw that you were doing excellent things with it, 3) thought that you could make an outsized contribution to their company, 4) gave you a cherry on top of a regular employment offer.

Yes, an entrepreneur's startup dream has failed, but on an individual level there are lots of positives.

(Note: I have not been acqui-hired but I have ran 2 startups that fizzled and were sold at low amounts, far below what we wanted. I don't consider them failures because, at the end, there was a monetary payment, but they were nowhere near as successful as we wanted them to be. And I ended up getting a real job after the exit.)

<comment><USER3> I suppose it depends on what you want out of the startup. If you want to change the world, an acqui-hire is a failure. If you want to make money, it can sometimes be a success.

<comment><USER4> > If you want to change the world, an acqui-hire is a failure.

Why? Let's assume that's Google's intention -- changing the world. If Google spends their resources acquiring a company, regardless of whether it's for their tech or their employees, is it not likely that they're doing it to further such goals?

Personally, I'd surely feel better able to change the world with the resources of a company like that at my disposal -- especially if they're receiving me through an acqui-hire, rather than out of college by resume or similar.

<comment><USER5> You are assuming that all changes are equivalent.

If it is my goal to change the world in line with my vision, that is not the same thing as changing the world to align with Google's vision, though there may obviously be overlap.

</comment></comment></comment></comment><comment><USER6> Actually HR acquisitions vary a lot. At one extreme they're indistinguishable from failure, but not at the other.

They're equivalent to failure if the acquirer doesn't give the the founders any more than they'd give equivalent people recruited through ordinary channels. But there are some HR acquisitions where the acquirer gives them much more. It's twisting the meaning of the word "fail" to call those failures. The startup may not have hit the the proverbial home run (yet) but they've done well enough to convince someone to give them a lot of money. While founders may have other goals for their startups, that's usually the economic goal. For some (to be honest, probably most) the economic goal is the main one. And if you achieve your main goal, that's not failure.

<comment><USER7> Pedantic point: to be a success, the financial outcome from an acqui-hire probably needs to account for the financial sacrifices taken during the building of the company. You can get a much better deal from an acquirer than you would have from their HR process and still come out behind for having landed there via a startup buyout.

It obviously goes without saying that that outcome needs to be shared across the whole team, too.

Technically, wouldn't you also want the financial outcome to capture the risk that the startup was all going to come to nothing?

Finally, most importantly, and (admittedly) orthogonally: even with acqui- hires, what we're hearing are the "success" cases. Even those cases where the backbiting HN threads are tearing the company down for "obvious" failures, those are, relatively speaking, successes. We don't hear about the majority of seed-funded startups, which don't get any offers at all.

<comment><USER8> Prior opportunity cost is a sunk cost. The "exit" needs to be evaluated based on realistic alternatives at that point (i.e. keep going or shut it down). The fact that you may have left money on the table to join a startup no-longer factors into the equation. It comes down to making the best choice given all the current alternatives, not all the possible past alternatives that could have been taken.

<comment><USER7> The question isn't, "is the acqui-hire the rational next step for the founders?" We can assume that acqui-hires virtually always are.

<comment><USER8> If sunk costs (based on missed opportunity cost) factors in, then you also need to know what future earning opportunities would be for all (or most) founders/employees had they taken a job in Big Corp vs working at the startup that was acquired. You'd at least want to be able to realistically forecast earnings over the next 10 years. If they've increased their future income by more than what they gave up, it's a net win.

The problem is that's impossible to accurately forecast. An additional problem is that the basis is only financial, when (most?) startup employees aren't there just to make the biggest possible payout. There's an increase in responsibility and autonomy across the board in a startup. How is that valued for each individual?

The point in saying "was the acquisition a success" can only accurately be viewed by looking at the other alternatives at that moment. Any other analysis is significantly flawed.

<comment><USER9> Think about a repeated game?

Also "The problem is that's impossible to accurately forecast" is true, but somewhat trivial. The initial investment and the M&A exit valuation are are subject to same critique, no?

Examination of the final node , while rational (is this the best out?) is not the right framework for evaluating the _investment_. To do that, one would think you looked at the deployment vs recovery (en toto), taking into consideration time (&tc).

<comment><USER8> I think any other analysis is too complex to offer any real insight. We can look at the NPV of the possible future earnings, to get a better idea. For the given opportunity cost, what's the impact on future earnings (over the next 10 years or so)? Does working at a startup that gets acqui-hired give you a potential to make earn more in the future? If so, how much more?

What if you break even in the long-run, but you value autonomy over money? So you get a couple additional years of more autonomous work in for the same total money. That's still a win, but we lack the financial forecasting instruments to properly value that. The same can be said for all other non- monetary possible motivations for working at a startup.

Looking at the money you may have given up, and requiring that ALL of that be made up in one lump sum to be a success event seems silly. It misses future income (which is relevant and can/should also be forecasted), as well as a number of other salient factors.

Any financial model we come up with, will still be just an opaque gage. So if we're really just looking for a simple heuristic, looking at possible alternatives is an ideal choice (but as heuristics go, which all evaluations of this would be), it misses some things. I'd still argue it's the best simple evaluation metric, and that we're not losing much by foregoing a more complex analysis.

<comment><USER9> Referring back to PG post,

Exit A | Nil value added = Failure

Exit B | Some value added < capital invested = 'not a failure'

Then the qualification was added

Exit C | Value added > capital invested = Success (threshold case)[1].

That is just objective data/nomenclature. Ex post and not complex.[2] Not forward looking. Not "personal".[3] Exit B is the typical case "Acqhire" or HR acquisition [4].

You, then raised the special case[5]:

Exit B2: Value added != face value consideration [6]

and also presumably,

Exit B3: Value added > face value consideration >?< Capital Invested

>>This murky area = _PR SPIN ZONE_.

My comment on game theory was to consider threshold success as [7]:

Exit B4: Value added + Reputation impact [8]+ face value consideration > Capital Invested.

This would mean some deals, even though they are not a financial success, if cash consideration was the only variable, still might be a legit "win" for everyone involved, when reputation is considered. __Note: LHS terms, when distribution not only total amount is considered, have a feedback loop __

Edit: formatting

Notes:

_____________

[1] Ideally, includes return = opportunity cost

[2] Final node optimization, is fair question. But tconsiders that a forgone conclusion. Note Tpacek's comment: _tptacek | link The question isn't, "is the acqui-hire the rational next step for the founders?" We can assume that acqui- hires virtually always are._

[3] The game theoretic optimization of the final node is messy. Don't be short sighted. Keep in mind, playing nested sequential games.

[4] Although logically, the product could be shut down in C.

[5] This is special vs a typical exit, but obviously common to [B] type Acquires.

[6] The "face consideration" is what goes to the equity of the startup.

[7] If you handle the exit well [3], reputation >> 0 is very possible, assuming a recurring game, etc.

[8] For both the investors and the team.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER10> This matches my view on the acqui-hire. A view that I didn't feel was reflected elsewhere, let alone by a top HN poster. This lack of validation of the view surprisingly mattered to me, it made me uncertain of the strength of my own opinion.

My current position is that last year I was just shy of a 6-figure salary, but also had a "lifestyle business" (read: number of websites) that are successful as projects (but exist as a stable and growing business).

Late year I made the decision to quit the comfort of the salaried position, to use the projects as the bread and butter and to build a technology based product and company.

I've now been approached with a serious offer from a large company in my sector, and a somewhat serious approach from a medium sized company in this area (sports related online communities).

During discussions it's become obvious that they're willing to somewhat inflate the offer for the community to acquire me fully too. That is they're not interested in an offer that doesn't include me and the offer is inflated to make that attractive.

Discussing this with non-startup friends, not one of them can fully comprehend why I wouldn't accept a swollen bank account and an envious salary.

For me, the thing that I deeply believe is that the technology startup hasn't even shown its' potential, and nor has it yet failed... in fact, I've barely started.

I quickly came to the conclusion that an acqui-hire is (right now) the worst possible thing that could happen. The end result would be the same as failure, and were I to have failed then not taking the money would be foolish. But right now it's so premature that I feel that to allow myself to be purchased is tantamount to seppuku.

It's really good to see that opinion shared. Most seem to celebrate the big earnings for founders and the cash-out for investors... but all I see is the wasted potential.

<comment><USER11> This is a great point. If you're not to the point of running out of money, and you don't yet have substantial evidence that the niche you've targeted is severely limited, considering an acqui-hire seems silly -- unless that was really your goal to begin with.

This makes me wonder at what point in the life of the startup most of these acqui-hires are occurring.

EDITED TO ADD: Further reading (e.g.: <http://news.ycombinator.com/item?id=4425364>) suggests that indeed, the usual point at which an acqui-hire becomes relevant is when the business is on the verge of failure.

</comment></comment><comment><USER12> Spelling an acquihire as failure reminds me of "If you're not first, you're last!" I don't know that it's a good way to look at things.

First, if you get out of your startup for what amounts to a signing bonus and a job at a cool company, life could be worse. Much worse, in fact.

If you set out to change the world and didn't-- c'mon, VERY few people are "changing the world" with a startup. The world, and your customers, will go on if you go to work for someone else.

Building a business is not for everyone. If you realize after you've started a business that you suck at it, there's no shame in saving face and getting out with what you can!

But yes, it's certainly not as exciting as a lot of these companies make it sound in their press release, and it's certainly not something anyone will remember a few days later. It's not placing first, but it's not last either.

</comment><comment><USER13> I'm not entirely sure this is true. Especially for service-based businesses. If we're talking about the web/mobile app world, then sure, agreed. There's a product or tangible service being provided that's getting shut down.

However, for service-based businesses, like architectural/engineering firms or consultancies, there's really no other form of purchase, other than to just funnel the profits to a different place. When you buy one of those businesses, _you can only buy the people_ , as there is little to no IP. If the name has enough cache, you can continue on with that name, but if it's a competitor, you're better off just folding them into the main brand.

As an example, my dad's an engineer. He sold his fairly successful business that he had run for 15+ years (it was a lifestyle business) because he was just sick of the bookkeeping--all he wanted to do was be an engineer after 15+ years. So he sold, and went to work running the engineering department specific to his practice of the place that bought him. Now, he gets a predictable income, no bookkeeping, and more reasonable hours. I don't consider him a failure in the least.

<comment><USER14> One of the most valuable assets of a service based company is there reputation, Rolodex and their phone number. Someone calls a plumber to come out and the guy at the other end says, "we changed our name to X" most people don't hang up and they don't actually care they just don't want to look for another plumber.

</comment></comment><comment><USER15> ChuckMcM made a post recently that was the most profound thing I've ever read on HN. I'm going to post the link here so you can shower Internet Points on him:

<http://news.ycombinator.com/item?id=4425364>

<comment><USER16> Really interesting read. Thank you for posting the link. I certainly would have missed this otherwise.

</comment></comment><comment><USER17> What counts as failure for an investor can be a big win for a founder.

Suppose a founder is in a dead-end job, but doing a startup for a year and a half leads to a much better job with more pay. That's a BIG win.

</comment><comment><USER18> Business owners seem to enjoy being acqui-hired -- not as much as selling company for a couple millions, but it's still quite good nonetheless. On the other hand, investors may get little, if any, of return on an acqui-hire. See article in which Michael Arrington admits openly that [http://uncrunched.com/2012/08/26/investors-dont-like- acqui-h...](http://uncrunched.com/2012/08/26/investors-dont-like-acqui-hires/)

If an acqui-hire is failure for anybody, then it's a failure first and foremost for the investors.

In his `About', Jacques states openly that he represents investors' point of view:

 _> I do this [[verifying that what a company says it sells and owns is actually true]] work for several renowned Venture Capital firms in Europe(...)_

<comment><USER19> Investors shouldn't like acqui-hires unless it is an agreed upon goal in the first place. In fact, I guess that investors wouldn't appreciate any misunderstanding of goals on any level, and it seems to be an oft-cited reason for entrepreneurs losing their jobs at the behest of venture capitalists. But if I had $1 million to invest into a business, and from my experience I had a reasonable expectation that a company I'm investing in could be acqui-hired for $50 million, and we agreed upon that from the outset, then I could see myself making that deal and being happy when the result came to fruition.

<comment><USER14> A lot of Acqui-hires are a choice between 98% chance of total failure vs. x% of their initial investment back. It's not a goal it's simply a way to cut their losses when the company is on their last legs.

<comment><USER7> This is true, but as has been pointed out repeatedly, even if a company faces a 98% chance of total failure, many investors would prefer they chase the 2% chance of success rather than recovery of X% of their investments. VC investments either win or they don't; salvage isn't interesting to them.

</comment></comment></comment></comment><comment><USER20> The funny thing is that 'acquisition' is, most of the time, also a failure. Here we get spoiled all the time with the big time acquisitions, but, in reality, acquisitions happen more often at a lower scale, I can tell you that because my company is getting acquired, not for a price I'd like to sell it but just to get it out of my way to attempt other endeavors.

I know of espectacular failures that end in acquisitions, I'm talking about companies raising tens of millions of dollars and sell for six figures.

</comment><comment><USER21> _"What happens is that instead of going bust on a failed idea all parties agree that it is better to put a positive spin on things so they present this fantastic acquisition story instead of folding the company and going bust."_

This does not hold water. What's in it for the party that puts the cash on the table? Why are they paying the cash for the supposed failure?

<comment><USER22> The acquiring company is paying for the team. In the Bay Area at least its really hard to get those 10x employees that Paul talks about to voluntarily come to work for BigCorp sometimes.

In an acquihire situation it is common that the incentive given to the team members to come to work for BigCorp are time locked such that the team members have to put in anywhere from 2 to 4 years at BigCorp to collect that reward. Amongst people who have done this it is sometimes referred to as 'doing time' since leaving to do another startup isn't an option unless you want to get none of the incentive.

As Jacques hints at there are lots and lots of different deals, from the guy who is up to his eyeballs in credit card debt to a company that has gone through a couple of rounds of VC funding.

</comment></comment><comment><USER19> One observation. I posit that in certain situations, when from the outset a startup sets out to attract a microsegment which is the subset of an existing market that is owned by a major competitor, and furthermore has the explicit goal of being acquired for somewhere between $5 to $50 million by one of those major competitors, that this is valid. Being that in select situations this is a valid undertaking, it must follow from this that the actualization of this explicit goal represents success, and not failure, neither on the part of the founding team nor in terms of product development. Perhaps the dollar amount I cited here is what the OP would consider to be a "buy-out offer [that] is spectacular", but to the extent that it isn't, it's ostensibly wise to consider the opposing viewpoint.

</comment><comment><USER23> This has been my experience. I think people tend to read too much into acqui- hires. The reality is that acqui-hires seem to typically be a means of salvaging _something_ from a failing company.

</comment><comment><USER24> Even if some people have HR acquisitions aligned with their definition of failure, I don't really see why that's so important. Because of the stamp or stigma they can put on someone maybe? I thought only Europe had that problem (being from there).

Startups fail all the time. It means people are trying. That is way more important to me.

The only thing I don't like to see is that good entrepreneurs get comfy at big companies with mediocre output. But in my experience that doesn't happen often.

</comment><comment><USER25> ice cube said "life ain't a track meet, it's a marathon".

you take risks. you build something. you learn to build and manage a company. you learn to raise capital. you learn to negotiate a buyout. you learn to ship products and support customers.

for business, personal or any variety of reasons, the founders decide that being acqui-hired is their best option, and have an entirely new set of skills to apply to their next business iteration.

but you're labeled as "failures" by this jacques mattheij.

i don't agree with him. not at all.

teddy roosevelt said:

 _It is not the critic who counts; not the man who points out how the strong man stumbles, or where the doer of deeds could have done them better. The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood; who strives valiantly; who errs, who comes short again and again, because there is no effort without error and shortcoming; but who does actually strive to do the deeds; who knows great enthusiasms, the great devotions; who spends himself in a worthy cause; who at the best knows in the end the triumph of high achievement, and who at the worst, if he fails, at least fails while daring greatly, so that his place shall never be with those cold and timid souls who neither know victory nor defeat._

</comment><comment><USER26> Beyond the obvious rationale behind acquihires... they're good for the startup ecosystem because the reality is that not everyone can be an Instagram.

They're usually a great deal for the founders and the company so it's win-win situation unless of course your definition of success is a billion dollar exit. Not to mention the learning curve and challenges that entrepreneur experience and overcome which in my opinion is priceless.

</comment><comment><USER27> I'm not sure if it fits the story 100%, but this is exactly how I felt when Sparrow got acquired by Google. I use Sparrow on iOS daily and I hate the fact that there's a possibility we'll never get push notifications.

</comment><comment><USER28> That is true, but even so, acqui-hires are good for all of us, because they make investors less cautious.</comment>


Ask HN: When / how did you untangle personal accounts of the tech founder? - <AUTHOR> My current venture started as a personal project. That means that all of the passwords are tied to me personally. This means the domains are in my personal registration account, the code is a private project under my github user, the 3rd party APIs we use are tied to my personal developer account, etc.
As I am looking to grow from using occasional contractors to building a tech team, it is probably time to start untangling all of that. I assume this is fairly common among HNers.
So, when did you untangle the mess of accounts? How did you do it?  Did you create a firstname.lastname@example.com email for all of the account logins, use a different email per service? Store API keys in something like LastPass or a secure Evernote folder?
Or did you just leave it alone? It is my company and I don't have outside investors, so I don't plan on going anywhere anytime soon. <comment><USER2> I prefer to use external SaaS that allows multiple members of a team to login independently, so we don't have to worry about sharing a single username/password. For things like SSH keys and GitHub repositories, we pay for private organization repos that are shared with the team. API keys, passwords, etc are stored in a private GitHub repository that is only accessible to myself.

One interesting aside to your query is "what happens if I get hit by a bus tomorrow?" That is, will the startup cease without its CTO? My solution has been to keep a handwritten password in a safe in my house, and provided an extra key to a trusted third party (my parents). So if worst comes to worst, my legacy will not end when its domain needs to be renewed.

Hope this helps, and good luck!

<comment><AUTHOR> That really does help. I am using private repos now and will shift them to an organization. However, I had not thought of storing password and keys in a repo. The sharing doesn't seem very granular, but it makes it easy to document and store the history.

I like the safe idea too.

Very helpful comment.</comment></comment>


Yahoo BOSS API is no longer free - <AUTHOR> http://www.techcrunch.com/2009/02/11/yahoo-prepares-to-turn-on-the-meter-for-its-first-web-services-business/

<comment><USER2> This headline is typically misleading.

The first 10k requests a day are free. Previously it was 5k.

Once you pass that threshold (it's not _that_ low) it starts being charged according to your use.

I'd love to hear feedback on what people think about this pricing model. Please feel free to leave a comment here or email me croucher at yarrhoo dot com (remove the pirate misspelling).

Edit: Whoops forgot the disclaimer. I work for Y!

<comment><USER3> > The first 10k requests a day are free. Previously it was 5k.

The 5K limit you refer to is from the old Yahoo Search API, Yahoo Boss allowed "unlimited queries".

<comment><USER2> My bad. :)

</comment></comment></comment><comment><USER4> So what does this mean for duckduckgo.com ? They're based on the BOSS api and I figure that by now they're passed the 10.000 requests a day.

<comment><USER5> this was my first thought, too.

</comment></comment><comment><USER6> I think this is fantastic. I would way rather get charged a reasonable amount for a useful service than have to wonder if it will be around in the future or how they're making money off me.

</comment><comment><USER7> The title editorialises needlessly, and incorrectly. The API remains free for up to 10,000 queries a day. That is more than all the traffic the techcrunch network makes, so it remains free for most everyone.

<comment><USER8> If I understand well, Techcrunch uses BOSS API only for custom search of their sites. I would expect only a small fraction of their visitors search directly from Techcrunch sites.

The change would affect significantly somebody who uses API as a part of their primary function of the site [1], for example for some search mashup (like various Cuil parodies or DuckDuckGo). For these, basically each page view could be one (or more) API requests.

[1] <http://mashable.com/boss>

</comment></comment><comment><USER9> Yahoo! should have announced this as the plan from the start. Its awful hard to give something away for free, then go back to charging for it. At the very least, they should have grandfathered everyone in who was already using BOSS.

I understand the desire to charge for a service like this, but the way Yahoo! handled this does not encourage me to use their services (I've used BOSS extensively).

<comment><USER2> Yahoo! did say that there was a pricing model coming in the future for BOSS from the start. I'm sorry you feel frustrated. I'd be interested to hear if you have any ideas about how we could have communicated that better. It sucks that you we flip-flopped.

Disclaimer: I work for Y!

</comment></comment><comment><USER10> I was wondering if anyone could break down the pricing plan for me. Talk about needlessly complicated... Also, if any current BOSS users can comment on how this will affect their operations, that would be awesome.

<comment><USER2> The exact breakdown is here.

<http://developer.yahoo.com/search/boss/fees.html>

There are two examples:

* Developer A submits 7000 API requests in a given day. Each API call requests search results 1-10. Since 1000 requests of this type cost 3 units (for a total of 21 units) and each developer gets 30 units per day for free, Developer A is not charged anything.

* Developer B also submits 7000 API requests. Each API call requests results 1-100. Since 1000 requests of this type cost 10 units (for a total of 70 units) and each developer gets 30 units per day for free, Developer B will be charged for 40 units (70 - 30 = 40). The price of 40 units is $4.00 (40 x $0.10 = $4.00).

It's also worth noting that pricing is in units of 1000 requests however we will charge per request, it's just not worth quoting prices for units smaller than 1000.

Disclaimer: I work for Y!</comment></comment>


Ask HN: Should you be full stack dev or specialise further into a stack? - <AUTHOR> I have always been back end dev with little front end experience but noticed a lot of jobs now are full stack and even pay better than back end. At the same time I always thought it's best to specialise in some tech than being a generalist. I am thinking in specialising into data engineering but would that harm my opportunities and salary as compared to full stack? <comment><USER2> Be jack-of-all-trades and master-of-one.

Knowing the fundamentals in other stacks will improve how you design what you master.

Be careful not to mistake fundamentals as the "getting started" part of something.

<comment><AUTHOR> so do you recommend a career in full stack rather than lets say data engineering?

<comment><USER2> In case you misread the "master-of-one" as "master-of-none", it's master-of- ONE :D

No I don't recommend to do that or otherwise.

What I was saying is that

Knowing more about infrastructure will improve you in data engineering.

Knowing more about frontend will improve you in backend.

Knowing about software development will improve you at being a team player.

Etcetera, etcetera.

For career, you might want to balance between what you're interested in and what's needed right now.

<comment><USER2> This might help [https://news.ycombinator.com/item?id=21194003](https://news.ycombinator.com/item?id=21194003)</comment></comment></comment></comment>


What comes after postmodernism? - <AUTHOR> https://www.tandfonline.com/doi/full/10.1080/00131857.2018.1462520 <comment><USER2> >On a more practical level, the wake of postmodernism is clearly visible in the educational arena. Because everyone's experiences are now privileged over investigation of a shared, knowable world, young scholars are increasingly finding venues for articles that tout their own experiences. Nowhere is this more conspicuous than in the humanities where alleged experience-based methodologies, such as autoethnography and 'action research,' have gained traction in peer-reviewed journals. With that traction comes increased Impact Factors when academicians cite the personal experiences of others as evidence to bolster supposedly scholarly claims.

This paragraph seems to be the "meat" of the article; standard complaints about postmodernism constitute the remainder. It is an interesting point, but it is not fleshed out very much.

<comment><USER3> Yeah. I was expecting some level of proposal. I expected the article to have more, so downloaded the PDF. Nothing more!

</comment></comment><comment><USER4> This sounds less like serious academics more like "kids these days, am I right?". Identity politics, nationalism, tribalism are all very pre-modern and just never went away. I think you could easily argue that they've diminished to an all-time low and not the other way around. The reason we hear so much about it now is that in past generations, race and class strata of society were simply an unspoken fact of life and the current trend of public whining is just a reaction to the walls coming down. Asking for social justice is not new, it's just being listened to now instead of stamped out.

</comment><comment><USER3> The sense of massive deja vu settles over me when I see these pieces. Or more accurately: hasn't this been done already?

I studied continental philosophy as a graduate student about ten years ago and have kept up since as much as possible.

Continental philosophy was the spawning pool for the loose cluster of tendencies[0] that form the concept of postmodernism in the imagination of most - Derrida, Foucault, Lyotard.

At this time, it seemed definitively that this set of ideas this lot was on the way out. There was even a term for what was bad about them, as captured in _After Finitude: An Essay On The Necessity Of Contingency_ by Quentin Meillassoux: correlationism[1]. The idea that human thought never "got at" the truth because of intermediate cognitive or societal structures or biases. There was a whole movement against correlationism called speculative realism[2]. In the UK at least, indeed, the focus of continental philosophy that preceded it seemed to oppose this postmodernism taken as a name for this cluster of thinkers. Broadly, a solid focus on Deleuze resulting in "new materialisms" (often scientifically informed) and a figure like Alain Badiou (Meillassoux's tutor) who very much attempted to stake out the ground for Truth with a big-olde-capital-T.

So to me that it is still a live term and people are talking about it so much is pretty strange. Of course that continental philosophy influences other discourses, and that both Derrida and Foucault were quite interdisciplinary in their work. So one could say this is some sort of institutional lag. But it is an odd thing to observe[3].

\---

[0] I say this because Foucault and Derrida are better described as post- structuralists and this is what they would have considered themselves as. Lyotard helped assist the terms with his work certainly in _La Condition postmoderne: Rapport sur le savoir_ but it was a term of societal diagnosis rather than support. I feel that postmodernism as a cluster term was the result of the reception of these theories in American literary theory departments.

[1] [https://en.wikipedia.org/wiki/Object- oriented_ontology#Criti...](https://en.wikipedia.org/wiki/Object- oriented_ontology#Critique_of_correlationism)

[2] [https://en.wikipedia.org/wiki/Speculative_realism](https://en.wikipedia.org/wiki/Speculative_realism)

[3] I'm not actually adjudicating here on the merits or otherwise of those thinkers grouped as postmodern. That's another topic.

</comment><comment><USER5> I see a great divergence coming: take a look at a culture divide in between rich Chinese cities, and the rest of the country. The divide is visible in everything from aesthetics in art, to attitudes to marriage, the proletariat and 1% are a world apart.

I see the same coming sooner or later to the rest of the world.

</comment><comment><USER6> I think postmodernism also affected journalism. It was more important to invite both sides of the argument rather than care about facts. But I think the attitude has been changing lately, with the ecological dangers and dangers of fascism that this system brings.

<comment><USER7> I think the explanation is much simpler. Inviting both sides is cheap and gets lots of controversy, which sells. Whereas finding and reporting the facts doesn't get you much attention, takes time (so the story is no longer fresh), money, and exposes you to legal risk if you got any of the facts wrong (and even if you didn't, you may have to defend yourself in court).

One option is easy, cheap, quick, safe, and attracts a large audience. The other is the exact opposite. It's obvious which one an amoral, profit seeking corporation would choose.

</comment></comment><comment><USER8> It's gratifying to see a deep understanding of the origin and current reality of this situation emerge after so many years of chaos and culture warring. Hopefully with understanding, and greater exposure to society at large, will come a remedy.

</comment><comment><USER9> Post-postmodernism/metamodernism, perhaps best embodied by the type of "post- irony" found on imageboards?</comment>


Underserved kids learning to code ON PAPER need lab. - <AUTHOR> http://www.indiegogo.com/projects/a-computer-lab-for-the-scholars-working-overtime-team--2/x/2202753

<comment><USER2> This sounds like a really cool project - Getting kids involved in coding could really boost their options for education and jobs later in life. Having worked for non-profits, I have seen money for youth education programs go to waste but now as a coder I really think that the kids that actually like it and want to get involved could really have their life trajectory change for the better.

</comment><comment><USER3> I find this to be particularly interesting. While I agree, yes, these kids need some form of computers, from what it sounds like, you're choosing to use Mac Mini's. These are pretty high-cost computers, with much cheaper alternatives. Why not use a cheaper alternative?

</comment><comment><USER4> Computers are now part of basic literacy and ensuring all students have consistent access to them should be an absolute top priority for all school districts. If we can get students coding at a young age, even better!

</comment><comment><USER5> Any person that wants to learn to program should be given the opportunity and tools to do so, regardless of background. And, believe it or not, those tools do not stop at pencil and paper. Go SWOT!

</comment><comment><USER6> Wow, these kids don't even have computers?</comment>


First Picture of an Atom's Shadow - <AUTHOR> http://news.nationalgeographic.com/news/2012/07/120710-first-picture-atom-shadow-photograph-science-nature-smallest/

<comment><USER2> This may be a dumb question but what does the shadow fall on for the scientists to take a picture of it? If is is landing on the 'lens' then wouldn't 'silhouette' be a more appropriate term?

As far as I understand all matter is made of atoms so at the atomic level there wouldn't really be matter (wall, ground etc.) for the shadow to be cast on.

Amazing nonetheless.

<comment><USER3> It took a little googling. Here's a potential answer.

The paper the article is based on talks about "absorption imaging". Googling that I found another paper [1] in ArXiV which describes the method a little bit: "absorption imaging, where the attenuation of a laser beam passing through an atom cloud is measured, is the workhorse of ultracold atom experiments. The shadow cast by the atom cloud onto the CCD allows an estimation of the atomic column density."

And if I understood correctly, a CCD is a "charge-coupled device" [2], sort of a digital camera. And that's where the shadow falls.

[1] <http://arxiv.org/pdf/1101.4206v2.pdf> [2] <http://en.wikipedia.org/wiki/Charge-coupled_device>

</comment></comment><comment><USER4> The paper at arXiv: <http://arxiv.org/abs/1201.5280>

</comment><comment><USER5> Enhance it.

<http://www.youtube.com/watch?v=Vxq9yj2pVWk>

<comment><USER6> These are terrible, but really funny <https://www.youtube.com/watch?v=KUFkb0d1kbU>

</comment></comment><comment><USER7> So, what do we actually see on the photo? Is the black dot a shadow of the nucleus or a shadow of the electron shell? And these ripples are effects or the wave properties of light?

<comment><USER8> I'd also be curious about the effects of diffraction and whether the atom appears as a sphere. If so, can we expect to see a Poisson spot, which a bright spot in the middle of the shadow caused by constructive interference?

</comment></comment><comment><USER9> Actually it appears to be the spatial pattern of absorption of around 6 million photons. So technically it is a shadow, but it's not like you are flashing an atom from the right and taking a picture from above. I'd like to know more about Fresnel lens aberrations to have an opinion about the feasibility of such a measure.

</comment><comment><USER10> Interesting. When I read the title, I was curious about the practical use of that photo until I read that this would lead to study DNA inside living cells.

</comment><comment><USER11> I don't quite understand the how nor the consequences. How does this compare to crystallography?

<comment><USER12> You could use this for things that don't crystallize. It might even be easier to reproduce than crystallizing for things that can.

</comment></comment><comment><USER13> reminds me of Dune II</comment>


Mark Shuttleworth is not selling Canonical or Ubuntu – yet - <AUTHOR> https://www.zdnet.com/article/mark-shuttleworth-is-not-selling-canonical-or-ubuntu-yet/ <comment><USER2> >Actually, the question most of us wanted him to answer is: "After IBM paid a cool $43-billion would he consider selling Canonical?" ... Shuttleworth said, "No, I value my independence."

Seems pretty cut and dry to me. The rest of the article was just speculation probably just to get more clicks.

<comment><USER3> Indeed, with this in mind I don't understand the justification for the "yet" part of the title. Good clickbait I guess.

</comment></comment><comment><USER4> Does not make a sense to sell yet. It is now the biggest independent distribution in all categories. The more mature the market becomes, the biggest the value for Canonical.

<comment><USER5> Which market ? The consumer linux desktop ? :/

<comment><USER6> For servers, I believe Ubuntu surpassed Debian in popularity recently and is now the most popular distro for both desktop and servers. It's certainly the default option for many cloud hosting companies.

<comment><USER7> > For servers, I believe Ubuntu surpassed Debian in popularity recently

You're probably correct, but _man_ is that a sign of our industry's immaturity. Debian is a _stable_ and _free_ platform on which to build a product. Ubuntu is a fine end-user distro, but it is neither as stable nor as free as Debian.

<comment><USER8> I am truly sad when OpenSUSE and SUSE isn't in the conversation about stability and popularity for servers. They have been rock solid give you the option of a rolling release and paid support if you want it.

</comment></comment></comment></comment></comment><comment><USER9> He can't sell Canonical unless someone is willing to pay for it.

<comment><USER10> Microsoft does seem like a logical buyer...

<comment><USER11> My bet has always been on Amazon, they have the weird partnership and integration. Would make sense for their cloud business too.

<comment><USER12> It would be odd if they do. They seem to pushing all their Linux efforts on Amazon Linux 2, which is a clone of Red Hat Enterprise 7.

</comment></comment></comment></comment><comment><USER13> Could they do something like what Aardman Studios did? The company saves up money to buy out the owner at fair value then puts the shares in a trust and effectively makes the employees the owners

<comment><USER14> Owners of an unprofitable company unfortunately in the case of Canonical.</comment></comment>


Escaping the Safari sandbox with a kernel GPU bug - <AUTHOR> http://googleprojectzero.blogspot.com/2014/11/pwn4fun-spring-2014-safari-part-ii.html

<comment><USER2> Amazing writeup. An attack from top (javascript) to bottom (kernel bugs), while very clearly explaining the discovery and exploit of vulnerability in each layer. The attack is very impressive, and the writeup makes it seem easy, which is a great compliment on the clarity of the writing.

Of course, and as mentioned at the end, the actual discovery process was much messier :)

As a bonus, there are a lot of links to other interesting documents as well.

</comment><comment><USER3> This writeup, and the first part of this series, are amazing and incredibly instructive. But they make me embarrassed that anyone still runs or writes code that is so without memory safety that these bugs can exist.

<comment><USER4> The idea of passing around function pointers like raw values that way, or having a language+runtime without array bounds checks or checks for dereferencing invalid pointers is just frightening. We have tools now such that _if_ they had been around in the 60's/70's we wouldn't have these problems. So why not start rebuilding low level systems using better tools? Granted, if we rewrite kernels, drivers, encryption etc in tools preventing stupid low-level bugs, we likely end up creating new high level bugs that were squashed years ago in the old C code. Still, isn't this something that has to be done?

<comment><USER5> > We have tools now such that if they had been around in the 60's/70's we > wouldn't have these problems

Not for kernel development we don't.

The only modern, memory-safe language that gets close(-ish) to the performance of C for kernel development is Rust and it's a long way from being stable enough for mainstream kernel development.

And even a safe language like Rust won't prevent escalation problems like this if you're placing too much trust in incoming data. That's a design problem that has nothing to do with languages or memory safety.

<comment><USER6> Yes we have. Xerox PARC systems were mainly developed in Mesa after some bootstrap work in BCPL.

ETHZ OS were done in Modula-2, Oberon, Active Oberon.

Olivetti and DEC were using Modula-3.

Several OS were being done in Algol and PL/I dialects back when UNIX was being born.

C's ubiquity is a consequence of UNIX adoption by some successful startups in the workstation market.

If one of the other systems had enjoyed a similar adoption another safer systems programming language would have taken C's adoption.

<comment><USER7> If Minix had used something else, then Linus probably/might have used that.

</comment></comment></comment></comment></comment><comment><USER8> Great article! ... I'm glad I already disable hardware acceleration having hit kernel panics there on OS X before. (I did a write up, [http://www.brendangregg.com/blog/2014-05-23/osx-10.9.3-is- to...](http://www.brendangregg.com/blog/2014-05-23/osx-10.9.3-is-toxic.html), but it's much less interesting/useful than this blog post).

<comment><USER9> Still cool, thanks.

</comment></comment><comment><USER10> "And if you're still running OS X Mavericks or below then why not try it out?"

In other words: "insecure" or "unstable" \- choose one.

I'm all for upgrading to Yosemite, but this is a problem.

</comment><comment><USER11> I always feel a bit strange around security and exploitation people. Security is important, but it's so much easier to destroy and criticize stuff than to build something useful and try to balance all the aspects of a product.

</comment><comment><USER12> Thank you for sharing, this is a very good reading. I purchased a book about using buffer overflow to hack stuff. but I'm wondering how those kernel bugs were discovered?

<comment><USER13> If you want an excellent book on kernel security, I'd suggest buying "A Guide to Kernel Exploitation: Hacking the Core". It's a fairly technical book, so I wouldn't recommend it unless you have exploit and modern operating systems experience, but it's a good book that covers every major platform and a lot of details.

It's probably one of the best technical security related books I've ever read.

<comment><USER14> Thanks much for info on this book</comment></comment></comment>


Why Greatness Cannot Be Planned [video] - <AUTHOR> https://www.youtube.com/watch?v=dXQPL9GooyI <comment><USER2> The story of how Feynman found out about the Challenger disaster is quite interesting. It is not that he was a clever detective ferreting out the facts -- it's just that he tried something different and let himself be nudged along in the process.

To quote from his book "What do you care what other people think?"...

 _Well, a few days after the accident, I get a telephone call from the head of NASA, William Graham, asking me to be on the committee investigating what went wrong with the shuttle! [...] When I heard the investigation was going to be in Washington, my immediate reaction was not to do it: I have a principle of not going anywhere near Washington or having anything to do with government, so my immediate reaction was -- how am I going to get out of this? [Gweneth, his wife says] "If you don't do it, there will be twelve people, all in a group, going around from place to place together. But if you join in the commission, there will be eleven people -- all in a group going around from place to place together -- while the twelfth one runs around all over the place, checking all kinds of unusual things. There probably won't be anything, but if there is, you'll find it." She said, "There isn't anyone else who can do that like you can."_

</comment><comment><USER3> Steve jobs said something like: You can only connect the dots looking backwards. I've found that to be true in many ways. If you look at any success story, it usually involves many degrees of luck, chance, crazy coincidence, etc. From business stories, to how you met your closest friends, or even your significant other.

Of course, this is survivorship bias, and we're constantly missing great opportunities every day.. but it's still interesting how things turn out.

<comment><USER4> But there's a metalevel theory there. After spending years failing to learn music, I finally hit a few sweet spots. I couldn't be more wrong before. But knowing how failing can lead to knowing, how being wrong helps you map the possible space to home in the right leads you to a very different approach on discovery.

</comment></comment><comment><USER5> Some of the extrapolations from the picture platforms to other domains are a bit hand-wavy in the talk, but his response to the Edison question [0] is pretty enlightening.

Additionally - just pondering here - this heuristic of novelty seems present in human nature: \- the drive that scientists, mathematicians, researchers, and technologists have to discover new things \- the drive that hackers and artists have to make new and different things

Does anyone agree that these aspects of humans are in tune with what the subject of the talk, or are they more unrelated than I think?

[0]: [https://www.youtube.com/watch?v=dXQPL9GooyI](https://www.youtube.com/watch?v=dXQPL9GooyI)

</comment><comment><USER6> Found this pretty much enlightening, I think this applies to careers as well. When I look back at the steps I took towards getting to where I am now, I don't see any connection, they were seemingly random steps.

<comment><USER7> Didn't Steve Jobs say the same thing ? You cant connect the dots going forward. They only make sense when looking back.

</comment></comment><comment><USER8> This was much better than I expected from the title.

<comment><USER9> Agreed. The book has gotta be worth $20: [http://www.springer.com/us/book/9783319155234](http://www.springer.com/us/book/9783319155234)

<comment><USER10> The kindle version on Amazon [0] is slightly cheaper at $16.19.

[0] [http://www.amazon.com/Why-Greatness-Cannot-Planned- Objective...](http://www.amazon.com/Why-Greatness-Cannot-Planned- Objective/dp/3319155237)

</comment></comment></comment><comment><USER11> There are counterexamples, for instance, the Wright Bros. invented the airplane through a directed research and development process.

</comment><comment><USER12> Interesting talk. I really couldn't tell how much of it really meant something and how much of it was fluff like "power poses".

In any case he's been giving similar talks for a while.

[https://www.youtube.com/watch?v=tZBViI8ZaU0](https://www.youtube.com/watch?v=tZBViI8ZaU0)

</comment><comment><USER13> But there are still too many javascript libraries out there!

<comment><USER7> That's a very interesting point. When I look at React and React native , I do feel that they could be stepping stones to something really interesting.

The Decco app that was posted on HN only reinforced this idea. I feel that one day we'll be flinging fully formed react compoenents as fast as we fling for loops while coding today. Some form of smart component search and automatic insertion could speed up programming by a huge amount.

Abstracting out the DOM rendering means we could have universal components.

But these aren't here yet. You don't have to use the latest framework in your project if you don't need. But that shouldn't stop the experimentation and the evolution.

So go forth and write ye Single page app frameworks and ye Coffee script to brainfuck transpilers.

</comment></comment><comment><USER11> This fits right in with the Connections thread:

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

which is all about serendipitous discoveries.

</comment><comment><USER14> Speaking from an AI/ML perspective, I'd like to point out one flaw, which is that exploration (of unexplored states) is certainly something that can be incorporated into your objective function, or accounted for in other ways, depending on the specific AI/ML algorithm and domain. This is a very common thing to do in reinforcement learning, for example.

<comment><USER3> I think he just about says this in his talk when he discuses developing "novelty search". The applications to AI seemed more straightforward (don't blindly run up to a local maxima if your search space isn't monotonic), but the application to life is less straightforward but more interesting.

</comment></comment><comment><USER15> I'd like to hear arguments against his claim. Even better if it is a machine learning experiment that invalidates his idea.

It would be interesting to compare the two sides.</comment>


Show HN: Privacy Focus VPS WireGuard VPN on Immutable Servers - <AUTHOR> https://www.tunnelhero.com/ <comment><USER2> > Made wit <heart emoji> by a bunch of geeks in Melbourne, Australia

As a fellow Australian this ruined it all, the government has made it very clear they are targeting vpn's to comply with the draconian backdoor laws. It doesn't matter where you host it, as Australian citizens you are under that of jail for not complying, warrant canaries are illegal. Aussie privacy focused vpn is an oxymoron at this point.

<comment><AUTHOR> Fortunely I'm not an Australian citizen. Also we haven't been asked to put any backdoors.</comment></comment>


Common Windows apps still without DEP and ASLR - <AUTHOR> http://0xdabbad00.com/2012/12/05/finding-slop-common-windows-apps-still-without-dep-and-aslr/ <comment><USER2> This is one of those situations where the author's simplification makes his assessment dangerously misleading. In the case of DEP+ASLR, there's rarely any value in doing it partway. If every executable image in your process does not have DEP+ASLR, then the protection is often worthless because either the attacker will be able to generate executable pages or will have enough predictable surface for a ROP chain. However, to make that assessment against an application you also have to verify what the files are and when/where they're actually loaded. And of course, you have to look at how the rest of the application runs to verify it doesn't undermine the protection provided by ASLR+DEP (e.g. Java historically allocated all memory RWX, making DEP pointless).

Since I know Chrome well I can use it as an example assessment. The first thing he mentions is xinput1_3.dll, and he correctly notes that this is used only when a gamepad is connected. What he doesn't mention is it's used only on Windows XP, which has no ASLR support. Since DEP is essentially worthless without ASLR, this file doesn't really have any negative security impact. Of course, it would be best if this DLL simply had ASLR+DEP enabled, but unfortunately it's part of Microsoft's DX library and MS doesn't see the point in changing it (for the reasons I've described).

As for the oddly named installer files, they look like differential updaters, which are temporary files created during an update. They don't handle any malicious data because all of the data is embedded in the executable file and the whole binary's signature is verified before it's run. I'm not sure if there's something preventing ASLR+DEP on these files. I'd have to check with the Omaha project <http://code.google.com/p/omaha/> to verify, since they're a separate project and I just don't know it as well as Chrome.

<comment><USER3> Not to mention I don't think XP supports /NXCOMPAT anyway.

</comment></comment><comment><USER4> Why look at Firefox 11 when Firefox 17 is the current release? 3 out of 36 is the current result for Firefox, much better than 13 out of 34.

No DEP, No ASLR: /Mozilla Firefox/maintenanceservice_installer.exe

No DEP, No ASLR: /Mozilla Firefox/webapp-uninstaller.exe

No DEP, No ASLR: /Mozilla Firefox/uninstall/helper.exe

<comment><USER5> Sorry about that. This is what was on my computer. Apparently the updates have failed to work (I don't use Windows normally luckily, but that surprised me). Didn't realize that.

</comment></comment><comment><USER6> Respective linker flags are:

      ASLR -> /DYNAMICBASE
      DEP  -> /NXCOMPAT

From Wikipedia:

      Vista, Windows Server 2008, Windows 7, and Windows Server
      2008 R2 have ASLR enabled by default, although only for
      those executables and dynamic link libraries specifically
      linked to be ASLR-enabled.

That's by default. You can also force ASLR to be applied to any app by installing EMET and configuring it respectively -

      http://www.microsoft.com/en-us/download/details.aspx?id=30424

EMET also allows changing DEP protection from Opt-In to Opt-Out, which is obviously a good thing.

[1] ASLR -- [http://en.wikipedia.org/wiki/Address_space_layout_randomizat...](http://en.wikipedia.org/wiki/Address_space_layout_randomization)

[2] DEP -- <http://en.wikipedia.org/wiki/Data_Execution_Prevention>

<comment><USER7> Thank you for including EMET. I was about to post about this.

</comment></comment><comment><USER8> tl;dr: Even common Windows apps with massive user bases are still horrible about using even the most basic security features. Please use EMET on Windows to force these protections.

<http://en.wikipedia.org/wiki/Data_Execution_Prevention>

[http://en.wikipedia.org/wiki/Address_space_layout_randomizat...](http://en.wikipedia.org/wiki/Address_space_layout_randomization)

[http://www.microsoft.com/en- us/download/details.aspx?id=3042...](http://www.microsoft.com/en- us/download/details.aspx?id=30424)

</comment><comment><USER3> "The main binary is unprotected from DEP. Likely for backwards compatibility with sloppy plugins."

I think IE uses SetProcessDEPPolicy instead of /NXCOMPAT.

</comment><comment><USER9> DEP might be disabled on java because it breaks the JIT

<comment><USER10> DEP doesn't break JITs unless they're written incorrectly. Furthermore, the OP says that DEP isn't disabled on Java...</comment></comment>


10 "Best" Code Comments - <AUTHOR> http://aboukone.com/2011/11/08/10-best-code-comments/ <comment><USER2> <http://ycombinator.com/newsguidelines.html>

_If the original title begins with a number or number + gratuitous adjective, we'd appreciate it if you'd crop it. E.g. translate "10 Ways To Do X" to "How To Do X," and "14 Amazing Ys" to "Ys."_

<comment><AUTHOR> Thanks for that, will keep in mind!

</comment></comment><comment><USER3> /* You are not expected to understand this */

<http://cm.bell-labs.com/cm/cs/who/dmr/odd.html></comment>


Ask HN: How many WPM can you type, and what do you do for work? - <AUTHOR> I just feel like gaining some perspective on what kinds of typists frequent hacker news.
And, what did you do to improve your speed?
There are various kinds of typing tests online but here is a basic one we can refer to: https://10fastfingers.com/typing-test/english
I am hovering around 58 WPM on a good run without errors— I'm a web developer.
If this question is not within the rules, let me know. I am, still, sort of new here. <comment><USER2> I scored 23 wpm, 113 cpm here [https://typing-speed- test.aoeu.eu/](https://typing-speed-test.aoeu.eu/). I am a programmer.

</comment><comment><USER3> eh why not this could be fun, did one run with no errors total of 64 wpm.

background: novice/intermediate programmer/It guy, with some data entry experience.

Do not often push myself that fast while programming so, probably half that while doing so??</comment>


Safari to snub new security certs valid for more than 13 months - <AUTHOR> https://www.theregister.co.uk/2020/02/20/apple_shorter_cert_lifetime/ <comment><AUTHOR> Trying to find something from Apple, but only can find [https://support.apple.com/en-us/HT210176](https://support.apple.com/en- us/HT210176) which talks about 825 days.

Here is another one with some more meat then the register article: [https://www.cbronline.com/news/apple- tls](https://www.cbronline.com/news/apple-tls)

Another one: [https://www.thesslstore.com/blog/ssl-certificate-validity- wi...](https://www.thesslstore.com/blog/ssl-certificate-validity-will-be- limited-to-one-year-by-apples-safari-browser/)

> Apple announced their unilateral decision at a face-to-face meeting of the > CA/Browser Forum (CA/B Forum) on Feb. 19, which is the industry standards > group that consists primarily of certificate authorities and several of the > major browsers.

> While there's been no formal posting anywhere that we've found by Apple > about this change, we were able to verify this information with some of our > CA partners who were in the meeting.</comment>


Vagrant for DevStructure: local and remote dev environments - <AUTHOR> http://blog.devstructure.com/devstructure-and-vagrant-sitting-in-a-tree

<comment><USER2> DevStructure is a great way for me to sandbox my dev environments and work on projects quickly.

Being able to use DevStructure on a VM makes a ton of sense as I don't always want to burn CPU cycles on a cloud server.

</comment><comment><AUTHOR> Wanted to add that we're working on support for Parallels and VMWare Fusion.</comment>


New Android Gaming Device - Devs get Android 4.0 device for test for only $99 - <AUTHOR> http://www.kickstarter.com/projects/playmg/mg-first-portable-gaming-system-for-the-android-ma

<comment><USER2> Developers have a chance to get their games as a pre-load on future devices, that's pretty cool!!</comment>


Netflix Is Shrinking the World - <AUTHOR> https://www.nytimes.com/2019/02/22/opinion/sunday/netflix-oscars.html <comment><USER2> The high-quality of dubs and subs is one of the reasons I still have a Netflix subscription.

I live in Spain and my SO doesn't speak English - Netflix allows us to watch content dubbed in Spanish and equally there is a lot of natural Spanish language content that helps me continue to improve my Spanish.

I used to download movies/tv shows and dealing with subtitle synchronisation and accuracy was always a massive pain assuming you could even find them.

The care Netflix takes over foreign language content is a real value-add over their competitors and the ever-present alternative of piracy.</comment>


ZZ is a modern formally provable dialect of C - <AUTHOR> https://github.com/aep/zz <comment><USER2> I find the basic idea of this project to be very compelling - I was thinking aloud on HN recently and arrived at roughly the idea this project is implementing. [0]

With that said, I really dislike the way they're describing their project.

When I read _safe dialect of C_ , I first assumed they meant they had developed a safe subset of C, or perhaps a very similar language, like OpenCL C [1]. Instead, they developed a new language which isn't C at all. Nothing wrong with that, but if I don't instantly recognise the syntax as C, I wouldn't call it a C dialect.

They also put _formally provable dialect of C_. Their language compiles to C code which is guaranteed to be free from undefined behaviour. This is not the same thing as a language where hard guarantees can be made about program behaviour, such as SPARK [2] or Dafny [3].

If the authors are reading this, I urge you to improve your project summary. Your language does not allow me to prove program correctness, instead it protects me from C's undefined behaviour. That's still a great idea! Please make this clear!

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

[1] [https://en.wikipedia.org/wiki/OpenCL#OpenCL_C_language](https://en.wikipedia.org/wiki/OpenCL#OpenCL_C_language)

[2] [https://en.wikipedia.org/wiki/SPARK_(programming_language)](https://en.wikipedia.org/wiki/SPARK_\(programming_language\))

[3] [https://en.wikipedia.org/wiki/Dafny](https://en.wikipedia.org/wiki/Dafny)

<comment><USER3> > Your language does not allow me to prove program correctness

Isn't that the whole point of the SMT solver?

What about this example (that doesn't compile)?

      fn bla(int a) -> int
          model return == 2 * a
      {
          return a * a;
      }

Isn't that verifying program correctness? A sibling of this comment claims that "the only thing proven is memory access validity" but, again, this example takes that down.

<comment><USER2> I agree that it is. Looking at the page, I can't see how far this goes.

Was my earlier comment completely wrong? Does ZZ allow the programmer to express a formal specification, e.g. to verify a sort function? If so, their examples are selling their language very short.

<comment><USER4> Prove of algorithms is possible as long as there's a known method of doing so in SMT. That means in practice, if someone has written a paper for formally proving an algorithm in SMT, you can mostly copy paste the proof.

zz is developed in parallel with a large project using zz and new syntax sugar features will surface slowly as they become practically useful.

That being said, it will never replace external formal verification with something like coq. They serve a different purpose.

<comment><USER5> What's the large project using ZZ? Or is it behind closed doors? This appears to be an entirely different ZZ programming language: [https://scratch.mit.edu/discuss/topic/80752/](https://scratch.mit.edu/discuss/topic/80752/)

<comment><USER4> it is [https://devguard.io/](https://devguard.io/) which is being rewritten from rust to ZZ in this branch [https://github.com/devguardio/carrier/tree/zz](https://github.com/devguardio/carrier/tree/zz)

<comment><USER6> Very interesting.

Can you tell us a little more about the reasons of the rewrite from rust?

<comment><USER5> I'm not involved, but one obvious answer is: broader portability than Rust (this is explicitly called out in the ZZ article). Clearly devguard is targetting a broader set of devices than the limited set Rust currently targets (x86; arm, mips, riscv in tier 2, with various caveats for bare metal targets).

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER7> > where we still program C out of desperation

I agree it's the standard and the only _thing that actually works_ (author's words), but it's still a pleasure for me to write and have to deal with C (for embedded). I'd be desperate if I have to be forced to deal with _huge_ different paradigms because _pointer problems_ or _insert-your-C-rant-here_. C is not going to be replaced on embedded any moment soon.

<comment><USER8> > C is not going to be replaced on embedded any moment soon.

Why? Doesn't for example Rust without stdlib already cover the use cases? Note I'm not experienced in embedded.

<comment><USER7> My personal opinion, is basically for 3 reasons:

1) There is no need to. C already has all we need to build our systems. The rest is seen as overhead/over-complication.

Regarding Rust, I try to keep up to date about its progress. Unfortunately most of the diseases that Rust _cures_ are not much of a trouble in embedded. My last UB, memory leak of loose pointer happened years ago. It will happen again and when it happens, I'll debug it. That's it. I'm not afraid of UB or dealing with pointers, even if there are 10K Rust users trying to FUD me. I know what I'm doing. Every embedded/kernel/driver developer know what they are doing. When shit happens, that's it, no big deal. You plug your debugger and solve the issue. It's not a nightmare that chases us in the middle of the day.

FUD alone is not enough for switching. So, why should I start thinking that a variable cannot change, because it's a constant (wasn't it a variable?), unless it can mutate, so it's a constant variable that can change because now is mutable?

Or constrain myself into borrow-checker torture for a thing I can do in a couple of instructions?

 _WHY?_

2) This is not about a _language problem_ , is about solving a _programmer problem with language_. If C = math, then you cannot do math _simpler /better_ because today's mathematicians are sloppier. Or because bosses pressures people to deliver crappy products.

I'm not a genius. I'm far from it, and if any seasoned C programmer challenges me I'll probably run away. But embedded/kernel/driver development is harsh, so if a developer thinks that he/she cannot make it because _language_ , then it's mostly about searching for an excuse. Time to change jobs.

The key is to think that a lot of people did (and does) a lot with so much less, for 40 years now. It's not a language problem. People have to learn to deal with it.

I was there too 20 years ago, when every C++ developer was afraid that they would lose their jobs because C#. It never happened. C++ is still one of the most used languages.

3) In my case, there are official libraries from manufacturers you have to use. Sometimes receiving customer support depends on if and how you use those libraries. All those libraries are in C. All the support is in C. All the examples are in C.

Yes, I know there is that engineer that has a Github repo with a library that works fine with that STM32 for that specific language, that now is getting support for embedded so in 5 years we could _maybe_ put something in production. But, not for now.

Sorry for the length. Edited some typos.

<comment><USER9> > Every embedded/kernel/driver developer know what they are doing.

Yet we still see security issues in all of those. I'm not saying that everything should be re-written in a different language, but C developers saying "I'm a good developer, all those safety mechanisms would hold me back" doesn't hold water considering all the security vulnerabilities we see that would have been prevented if they had used a language with better safeguards.

<comment><USER7> > Yet we still see security issues in all of those

That's the typical excuse. That's the FUD I mentioned about. Bugs will keep existing and so security issues, no matter the language you use.

<comment><USER10> But if we get rid of a whole class of bugs and vulnerabilities, the number of bugs will go down, no?

<comment><USER7> This is a common way of thinking about it, but nobody really knows. It's purely a conjecture. There is no data to back it up, and it just appeals to common sense.

Should everybody drop C/C++/whatever and rush into the Rust train because Rust people has _conjecture_?

I ask the opposite question. What would happen if the only programming language left is C? Wouldn't we become better programmers and raise the bar so high that the bug count drops to 0?

<comment><USER11> > _Should everybody drop C /C++/whatever and rush into the Rust train because > Rust people has conjecture?_

The way these things usually work in practice, the evidence that a new paradigm improves things usually builds up slowly. There will never be a point at which someone proves mathematically that C is obsolete. Instead, the gentle advantages of other options will get stronger and stronger, and the effectiveness of C programmers will slowly erode compared to their competition. At first only the people who are really interested in technology will switch, but eventually only the curmudgeons will be left, clinging to an ineffective technology and using bad justifications to convince themselves they aren't handicapped. Is Rust the thing that everyone except the curmudgeons will eventually switch to? Who knows, but if you don't want to end up behind the industry then it might pay to try it out in production to see for yourself. If you don't make room for research and its attendant risks you will inevitably fall behind.

<comment><USER7> I'm sorry you see things in terms of _competition_ and _curmudgeons_. But I see your point, it's just another type of FUD: don't stay behind and adopt Rust because you'll be a curmudgeon.

<comment><USER11> Not exactly, I'm saying that if you stay behind and don't adopt _something_ , where that something is whatever the industry switches to after C, you will eventually be left behind. Of course it is also possible (and likely for many people) to die or retire before that happens. It's not like C is going away any time soon.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER12> This is a great achievement in making formal methods accessible in pragmatic terms - something that actually works and can be used by normal humans.

Would be nice to have an actual microcontroller example.

> The standard library is fully stack based and heap allocation is strongly > discouraged

:/ \- I can see why this is done, as it's hard, so banning it to make the problem tractable works. But it's also quite inconvenient. On the other hand, "MISRA C:2004, 20.4 - Dynamic heap memory allocation shall not be used."

<comment><USER13> Unless it has changed, SPARK also forbids dynamic allocation.

<comment><USER14> It has changed: [https://blog.adacore.com/pointer-based-data-structures-in- sp...](https://blog.adacore.com/pointer-based-data-structures-in-spark)

</comment></comment></comment><comment><USER5> Pre- and post-condition annotations (`where` and `model`, respectively) are great. It's nice to see those in a new language.

Syntactically, this seems more like a Rust dialect than a C dialect. The primary relation to C seems to be portability (transpiler) and integration (ABI). This is true of most C-transpiled languages, though.

It's certainly cute, and potentially useful if your program is small enough to be solved by a SAT solver. Ideally relatively quickly, or those compile times will be poor. I wonder how it deals with machine registers, which are often something you would be using in embedded C.

</comment><comment><USER13> I though this would be more like Frama-C, in this spirit it doesn't look like C to me.

So not sure about possible adoption among C devs, even when the idea looks quite good.

<comment><USER15> Right, I wonder why they didn't build it with a C-like syntax?

</comment></comment><comment><USER16> Very cool idea! What I love about C is that all sorts of programming language can talk to its ABI and that it fits well with low level programming.

However it is a cumbersome and unsafe language. This seems like a very nice solution. You can write in a much safer language while producing C code which does not look too alien relative to what you wrote

I have been interested in Rust but thinking it looks a tad too complicated. This may be a happy inbetween.

<comment><USER17> I'd expect that a formally provable language would be _more_ complicated to write in practice than Rust. Take this example for instance:

>you must tell the compiler that accessing the array at position 2 is defined. quick fix for this one:

        fn bla(int * a)
            where len(a) == 3
        {
            a[2];
        }

In Rust you don't need the where clause, the `a[2]` operation will just panic at runtime if the array is too short. You don't have to prove to the language that the access is correct.

<comment><USER18> > operation will just panic at runtime if the array is too short

Exactly, rust doesn't provide a good solution to this problem at all. Panics in rust are an escape hatch used to ensure the language stays "safe" in situations where the compiler can not prove a given behaviour at compile time, but where it would have made the language too ugly if you had to wire through Result types for all the trivial operations like adding two numbers.

In my experience, panics in rust have been a major source of pain. In contrast to an exception, which you can catch, a panic behaves more like an abort. At least it has been that way in the past. Now, with a lot of libraries using panics to signalize runtime errors, coding in rust has at some times felt like I was using a bunch of badly written C libraries that internally call "abort()" and kill the process when something goes wrong that would have been totally handle-able without killing the whole process. That's the benefit of using a safe language, right?

I think lately the rust "community" has become aware of this issue and IMO the way things are going is that that panics, as they are designed, should basically not be used. But, without proper exceptions, that brings you back to the situation where an operation as trivial as adding two numbers either produces a return code that must be explicitly checked or may silently fail and produce an "undefined" result in some cases.

<comment><USER19> A panic in Rust nicely captures the category of errors which the programmer asserts should be impossible, which generally cannot be recovered well from. A panic is kind of catchable, but it only works in the sense of killing only part of the process rather than the entire process (like abort does).

If errors are expected, then you should Result instead of a panic. If people are using panics instead of Result for these kinds of errors, then the library is wrong. I'm curious what examples you have where this is happening.

</comment></comment></comment></comment><comment><USER20> I like how they incorporate an SMT solver. They claim: "all code is proven". What does that mean? What is proven about the code? Absence of memory bugs, or actual correctness of algorithms?

<comment><USER21> That the code is provably free of C undefined behavior

<comment><USER2> Looking at the example code, [0] it's clear you're correct.

As I just rambled about in another comment in this thread, their project summary isn't clear about this. Still a great idea for a language though.

[0] [https://github.com/aep/zz/tree/master/examples/hello/src](https://github.com/aep/zz/tree/master/examples/hello/src)

</comment></comment></comment><comment><USER22> One question that isn't obvious from the overview:

This language compiles to C and asserts that your program will never exhibit undefined behavior; have they _proved that ZZ is correct_ , ie that it will definitely never output C code that exhibits undefined behavior?

If you really care about correctness, that seems important. I absolutely love the idea in general though.

<comment><USER3> This seems similar to bootstrapping theorem provers. Here is a HN discussion on one: [https://news.ycombinator.com/item?id=21358674](https://news.ycombinator.com/item?id=21358674)

</comment></comment><comment><USER17> So it's more like a C transpiler than a dialect of C IMO (it effectively looks more Rust-like than C-like). I'm not just saying that for nitpicking the obviously vague definition of "dialect" but rather because it's a very important feature IMO, and actually makes this project potentially more useful to me.

I'd be very wary of switching my toolchain to an experimental one in production, especially if I'm targeting some niche DSP. On the other hand generating C and then compiling it as usual seems less of a hurdle to me. They actually point that out in the intro but I thought it might be worth mentioning it here.

Now I just quickly skimmed the readme but do they explain how they deal with interfacing with standard, non-ZZ C code? I assume they need some sort of "FFI" bindings like Rust to make the code safe.

<comment><USER23> _It will always emit C into a C compiler which will then emit the binary._

Presumably we can dump the C before compilation?

<comment><USER22> Why?

For this purpose, C is a very convenient and very portable assembly language. You could use a verified C compiler like CompCert to convert it to machine code.

In an ideal world, there'd be no C compiler in the loop at all, sure. But in practice it's not causing any trouble at all in a ZZ -> C -> machine code workflow. Quite the reverse, targeting C has some major benefits. (There are C compilers that are very fast, very highly optimizing, very portable, and/or verifiably correct.)

 _Edit to add:_ just realised I might have totally misunderstood your comment, sorry! Apologies for jumping the gun if so.

If you just mean can we save the generated C to disk instead of compiling it, yes, I would hope so too.

<comment><USER4> Absolutely! The zz export command just dumps the C and SMT code along with makefiles for common build systems and stops there. Very handy for using it within other toolchains.

</comment></comment></comment></comment><comment><USER24> This is a very interesting idea. The world needs more languages that make formal provability practical.

And I think I found a typo: thery is_open(int*) -> bool; -- should be "theory".

</comment><comment><USER25> > Its main use case is code close to hardware, where we still program C out of > desperation, because nothing else actually works.

I think I'll stick with Ritchie's language over this fly-by-night invention.

</comment><comment><USER26> > Checking is done by executing your code in SSA form at compile time within a > virtual machine in an SMT prover. None of the checks are emitted into > runtime code.

Cool !

</comment><comment><USER27> VCC [0] was a project by Microsoft Research that was used to successfully prove Hyper-V correct, but unfortunately it seems to have been abandoned.

[0] [https://github.com/microsoft/vcc](https://github.com/microsoft/vcc)

</comment><comment><USER28> No mention of unions, discriminated or otherwise. Sums/unions are a pretty important abstraction, and a lot of C's unsafety can sneak in if you don't enforce discriminated unions.

</comment><comment><USER29> This is gold, if it will actually work.

I will cross my fingers, and try it.

</comment><comment><USER30> Way cool. But in my testing yices blows away z3 by ~ factor 10. (see solvecomp.sh in one of the example ssa dirs)

</comment><comment><USER31> Love this project. Super pragmatic (use an existing solver) and small scope (no template functions).

</comment><comment><USER32> I love this idea. Does anyone know what the compile-time performance is like?

</comment><comment><USER33> Is the name supposed to be a French dick reference like Coq?

[https://en.wiktionary.org/wiki/zizi#Noun](https://en.wiktionary.org/wiki/zizi#Noun)

</comment><comment><USER34> Okay, it's provable... what value do really get out of it? isn't the whole reason why we still use C because it gets so close to resolving (or at least acknowledging) hardware or platform-level implementation problems? we can continue to re-invent the language in isolation but you can't replace a hardware-level programming language in this manner.

<comment><USER22> It is surprising that the syntax is so different for a "dialect" of C, but apart from that --

If the semantics are very close to C, so you can do basically all the same stuff, but you _also_ get guarantees that your code will absolutely never hit any undefined behavior, that's _great_ and tremendously useful. It absolutely could replace C in applications where C is still the most useful and practical language.

It would resolve a couple of major headaches in existing C code: security bugs caused by memory overflows (caused by using arrays or pointers in undefined ways); and highly optimizing compilers doing weird things to your code, by exploiting undefined edge cases.

If I know my code will _definitely not_ hit any undefined behavior, that gives me a ton more confidence that it won't have stupid buffer overflow bugs and I won't get mysterious errors on certain platforms.

</comment></comment><comment><USER35> It can't be a dialect of a language if the compiler of said language doesn't compile it.

<comment><USER36> [https://en.wikipedia.org/wiki/Programming_language#Dialects,...](https://en.wikipedia.org/wiki/Programming_language#Dialects,_flavors_and_implementations)

Plenty of well-known dialects are not subsets of said language (/compiled by its compiler).

</comment></comment><comment><USER37> This is just another symptom of why OpenSource often sucks. Instead of somehow coordinating and focusing their efforts, everyone seems to need to start their own spin off "inspired" by other projects.

When do people realize that building a new language is almost always going to fail and only very very few languages ever reach anything close to adoption.

Instead of spending all this time writing your own doomed language, why not try to contribute to a project like LLVM or Rust and add your provable subset there?

The same goes for Linux, which is the paradigm of wasted efforts.

<comment><USER38> Bjarne Stroustrup never expected C++ to be very widely used. He made it anyway.

Alex Stepanov never thought that anyone would care about his ideas on generic programming. He pursued them anyway. They became the STL.

True, building a new language is almost always going to fail. The problem is, when someone starts working on a new language, _they don 't know if it's doomed or not_. It is good that 1000 people try, because from that we get one language that many people use, and 10 specialized languages that a few people use, and 10 languages that nobody uses but future people steal some of the ideas.

> The same goes for Linux, which is the paradigm of wasted efforts.

Um... what? Wasted because nobody uses it? Very much no. Wasted because it's a duplication of what was there before? To some degree, yes. But not everything in Linux was in Unix before it. And Unix couldn't run all the places that Linux does (smartphones to mainframes). So, no, Linux is not wasted effort.</comment></comment>


WebRTC video-conference API - <AUTHOR> http://developers.bistri.com/blog/

<comment><AUTHOR> How to build a simple video chat application in a few steps? Here is how: [https://api.developers.bistri.com/tutorial](https://api.developers.bistri.com/tutorial)

</comment><comment><AUTHOR> and check the fiddle: [http://jsfiddle.net/bistri/DJjcB/#base](http://jsfiddle.net/bistri/DJjcB/#base)</comment>