Hiring for Basic Income - <AUTHOR> https://blog.ycombinator.com/hiring-for-basic-income/ <comment><USER2> Apologies if this has been discussed extensively. But it occurs to me that the US (and maybe other Western countries) has a retirement crisis - ie. people have not saved nearly enough for their retirement, and state-related pensions/entitlements are a massive strain on the budgets.

So with that in mind, how the heck can these countries even consider rolling out a new "basic income" program? Doesn't this seem a bit incongruous?

<comment><USER3> Part of the idea is that with a basic income, there's no longer a need for many "social safety net" programs: disability, social security, food stamps, medicaid, etc. The money saved eliminating all these programs (and their nontrivial overhead) can be used to give everyone a modest basic income.

I'm not sure if this is true or not. You can find serious people with reasonable seeming numbers on both sides of that argument.

<comment><USER4> Right.. Basic income essentially wants to take mone out of the pot currently reserved for the needy and disabled, and distribute it to able-bodied people who choose not to enter the work force.

<comment><USER5> There's nothing inherently wrong with not entering the workforce in the post- scarcity society we are rapidly approaching. People can instead choose to spend time raising their children, practicing a hobby, or trying to start their own business without fear of not being able to support themselves.

Most humans naturally don't want to sidle idle all their lives, some will, but the vast majority will find some productive use of their time - a basic income means they don't have to work 40 hours a week just to survive so they can do what they really want to do in their spare hours.

<comment><USER6> _...a basic income means they don 't have to work 40 hours a week just to survive so they can do what they really want to do in their spare hours._

The data suggests that men, at least, really want to watch TV and take drugs. They don't spend much time raising children or on civic engagement.

Here is a good survey article:

[https://www.commentarymagazine.com/articles/our- miserable-21...](https://www.commentarymagazine.com/articles/our- miserable-21st-century/)

If you want to say "that isn't a true Scotsman/basic income", please explain how writing "basic income" at the top of the check would change things.

<comment><USER7> I'm assuming you intend to reference the discussion of disability benefits late in that article; the key difference between that and basic income is that disability benefits are received by people who are judged to be occupationally disabled, which fall into two groups:

(1) People who _have_ worked and are actually _physically unable to do so any longer_ (and, generally, for the same reason, inhibited in other important life functions), and

(2) People who _wish_ not to work so much that they have engaged in elaborate frauds to be adjudicated unable to work.

And, in _both_ cases, actually receiving money from work reduces their eligibility for payments and may jeopardize their eligibility to receive benefits at all.

I think its quite reasonable to believe that neither of those (nor the two combined) would be representative in their use of money and their actions when receiving a certain amount of money, _on top of_ the fact that receiving money which is partially conditioned on non-work induces different behaviors (even in the same set of people) than receiving unconditional funds.

<comment><USER6> The article discuss the fact that most of those who are consuming disability benefits are not, in fact, physically unable to work.

This is readily apparent from the fact that disability claims are strongly correlated with the economy; recessions do not cause people to become paraplegics. And this rise is in spite of workplaces and daily life becoming safer.

NPR also has an expose on rampant disability fraud, although they of course use more polite language: [http://apps.npr.org/unfit-for- work/](http://apps.npr.org/unfit-for-work/)

<comment><USER7> > The article discuss the fact that most of those who are consuming disability > benefits are not, in fact, physically unable to work.

That's a non-sequitur, as the distribution between group (1) and group (2) in the GP post is immaterial to the argument made there.

If you want to address the points actually made in the post you are responding to instead of throwing out irrelevancies, feel free to do so.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER8> For anyone who is interested, I actually recently started a basic income experiment of my own. You can check it out here: [https://www.swiftdemand.com/](https://www.swiftdemand.com/)

Essentially the way that it works is that anyone who signs up will receive 100 coins each day and they may be freely traded among users. Ideally over time people will start assigning real world value to the coins and then the daily income you receive from Swift Demand will function exactly how Basic Income is supposed to work. If anyone has any questions or suggestions relating to the service I would love to discuss them.

<comment><USER9> How is the experiment going. Are people using this yet?

<comment><USER8> You can check out some information on the stats page: [https://www.swiftdemand.com/stats](https://www.swiftdemand.com/stats)

I actually only released the website less than a week ago so it's still incredibly new, but people have already done some cool stuff with it. This guy set up a website to write haikus in exchange for coins [http://swiftpoetry.club/](http://swiftpoetry.club/)

I'm planning on setting up a service to allow people to more easily exchange coins into their local countries currency and develop an API so websites can more easily accept Swift Demand as a payment option, but these things are still in the pipeline.

</comment></comment></comment><comment><USER10> Shouldn't this be posted in the Who is Hiring thread instead? :P

</comment><comment><USER11> I suppose that one good way to research BI is by making the national lotteries provide a prize that basically corresponds to a BI, and then make sure that participants agree to partake in the research (e.g., surveys).

</comment><comment><USER12> Might want to fix this -> [https://blog.ycombinator.com/author/elizabeth- rhodes/](https://blog.ycombinator.com/author/elizabeth-rhodes/)

<comment><USER13> Fixed. Thanks for the heads-up!

<comment><USER12> Hmm, Elizabeth's author profile still show's Matt's info, for me...

</comment></comment></comment><comment><USER14> The cost of basic income in the United States is about equal to the cost of getting us off permanently off of fossil fuels.

This is going to send heads spinning as we decide which one we care about more, poverty or the environment.

<comment><USER15> Getting permanently off fossil fuels is a one-off cost. Basic income is an ever increasing and perpetual cost.

I don't think they are comparable.

</comment></comment><comment><USER16> > Hiring for Basic Income

So much irony in just four words. I love it.

</comment><comment><USER17> It is really cowardly to use throwaway account when posting.

<comment><USER18> We detached this subthread from [https://news.ycombinator.com/item?id=13708932](https://news.ycombinator.com/item?id=13708932) and marked it off-topic.

</comment></comment><comment><USER14> Sweet! Where can I sign up to receive my basic income?

</comment><comment><USER19> One alternative to unconditional basic income would be an presence-based minimum wage. The idea would be not only to replace welfare and social security and other conditional income sources but also replace the idea of the minimum wage with a funded mandate. I'm not sure where this idea came from, though I believe I heard it attributed to Milton Friedman (though I've not been able to find a reference).

The idea would be to have an auditorium, where you would come in and sit and do nothing, and be paid the minimum wage when you leave based only on the amount of time you spent in the room.

Individuals would be free to accept wages lower than the minimum wage for outside jobs, but employers would have to compete with that minimum wage for employees, so any lower wages offered would have to compete in other aspects -- pensions, tips, benefits, opportunities for advancement, etc.

Because this would require physical presence, it would naturally be self- limiting in some aspects of abuse; you can "sit" as many or as few hours as you wish, but you cannot use that time for other productive work, so there's a natural fall-off of benefits as you choose to work instead (rather than an artificial administrative "cliff").

There are other aspects which seem very vulnerable to abuse -- why not just sleep there, what about doing remote work on a laptop, what about setting up shop and selling hot dogs in the room, etc. And there are some aspects which seem logistically problematic -- how do people commute to the room, how many rooms do you need, what about people who have disabilities that prevent them from travelling, etc.

But generally all of these seem addressable, and some of them might just be self-regulating by social norms, so that there is a small but acceptable amount of leakage due to abuse.

It seems administrative simpler in some regards than UBI, in that the uniqueness of a recipient is more easily enforceable, and it doesn't just change the y-intercept of the income curve, but rather semi-truncates it, so might be less vulnerable to attempting to extract the income through rent increases.

It also more easily adjusts to location-based pricing sensitivity -- it's totally reasonable for a place like SF to have a higher "minimum wage" than a less expensive city (just as minimum wages can float from state to state), and the requirement for physical presence makes it harder to game this.

<comment><USER20> One of things I hope some sort of UBI-esque program would do is allow people to create value in ways that are currently economically infeasible. This solution stomps on that while keeping one of the worst aspects of our current system, which is feeling stuck in a position where you're creating little value/care very little about the work but are chained to it because of lack of options.

<comment><USER19> As I've mentioned in other replies, for the same amount of dollars pumped into UBI (where it has to be distributed to the entire populace), this system can distribute that money instead to a much, much smaller segment of the population.

If, say, 10% of people opt to participate in "wasted-work", then each will receive 10x the benefit they would get from UBI, meaning that would be able to afford to save up money, or work part-time and still have sufficient money to support themselves while they pursue the "creation of value in ways that are currently economically infeasible".

UBI sounds great, but on a dollar-for-dollar basis it just seems worse than this because the level of compensation cannot be as high.</comment></comment></comment>


Mysterious craters blowing out of Russia could mean trouble for the whole planet - <AUTHOR> https://www.cnbc.com/2017/07/30/siberian-craters-big-releases-of-methane-could-pose-broad-problems.html <comment><USER2> The guy in the video says:

"You don't really want to be relying on regulations, we learned all the way back in 2009 that those subsidies can be removed anytime."

What exactly do regulations have to do with subsidies? Aren't regulations the rules of the game where a government is keeping an eye out over an industry? If there are subsidies involved, aren't these separate from regulations? Are we seeing here a conflation of regulations with subsidies and therefore a message of "regulations are bad"?

</comment><comment><USER3> Which takes us back to this thread:

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

And the comment that best captured my state of mind regarding that tread:

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

<comment><USER4> Wouldn't greenhouse gases turn earth into a wet greenhouse?

A parcel of air that is near saturation may contain 28 grams of water per cubic meter of air at 30 °C, but only 8 grams of water per cubic meter of air at 8 °C.

So isn't it possible that runaway methane would turn Sahara green again?

</comment></comment><comment><USER5> Mysterious? The first bullet unveils the mystery. They're the result of melting permafrost which releases methane which causes more melting. Feedback loop? Yes. Mysterious? No. That's like saying "Mysterious acceleration when I press the gas pedal."</comment>


Show HN: Our app built at the Startup Weekend SanJose in 48 hours: Shout A Tweet - <AUTHOR> http://www.shoutatweet.com/support/agtzaG91dGF0d2VldHILCxIEVXNlchjcHww

<comment><USER2> Wait, what does it do?

It might be obvious once I sign in with Twitter, but I'm not likely to do that unless I know what it is.

<comment><USER3> I agree that it needs an About or an FAQ page describing the service. I sort of guessed what it does by the tagline "same tweet, same time," but I shouldn't have to. If I'm right about what I think it does though, it's really neat idea.

<comment><AUTHOR> We added a F.A.Q. <http://shoutatweet.appspot.com/faq>

Thanks for the feedback!

</comment></comment></comment><comment><USER4> I tried this, my gf announced our wedding shouting a tweet! Was really cool, now all our friends know about it, everyone was like really excited about the way we announce it!

</comment><comment><USER5> You need to type the complete URL due to DNS issues: <http://www.shoutatweet.com/>

</comment><comment><USER6> This project is awesome, congrats on building a cool product.

Wondering if there might be an opportunity for you to use this as a tool for marketers to get a trending topic on twitter or for political candidates to sign people up for their support?

You could drive some serious awareness if you had 10,000+ people all tweet one message at the same time.

<comment><USER7> Yeah...when I first heard about it, that's exactly what I thought.

<comment><USER7> Granted...I also thought...wow that could be spammy.

</comment></comment></comment><comment><USER8> This is really cool. I think I'll have an a-ha moment later today with a real practical purpose. It may be something to use at a sporting event or music festival or to get a politician to notice a specific cause. Keep up the good work.

</comment><comment><USER9> Be careful... some followers think the simultaneous tweet was a kind of virus!

</comment><comment><USER10> It has been am incredible experience, from the pitch to this launch in less than 48hrs. Thanks to the team for the effort.

Please, let us know what are you using our product for.

</comment><comment><USER11> Cool, now all you got to do is fill it up with twitter drones and you can successfully manipulate social media. Congratulations :P

</comment><comment><USER12> Is there a way where I can check the shouts that are waiting to be shouted?

</comment><comment><USER13> Excelent idea, I have a lot of words to shout! Thanks to create this app!

Another feature could be shout in a speific time.

</comment><comment><USER14> Really like the design and logo.

</comment><comment><USER15> This is cool. Good luck guys.

</comment><comment><USER5> This project is the winner!

</comment><comment><USER16> This could be so usefull...Good Luck! and..try to sleep after this pls :)

</comment><comment><USER17> nice job guys! congrats from the feelvox team :)

</comment><comment><USER18> Good project!!!

</comment><comment><USER19> It's a trending topic machine,

<comment><USER20> Agree

</comment></comment><comment><USER12> Awesome! It is really cool

</comment><comment><USER21> Nice, i really like it

</comment><comment><USER22> I like it. Good Luck!

</comment><comment><AUTHOR> We started working on this idea on Friday Night, and its been an awesome experience! We appreciate any feedback about the site, the idea and our pitch deck ( <http://www.slideshare.net/DFectuoso1/shoutatweet2> ).

We are presenting at 6:30ish, so any feedback is awesome!

<comment><USER23> \- get rid of the Comic Sans in the presentation

\- move the title of the slides to the top left

\- move the logo of the slides to the bottom left or right or delete entirely

\- The business model slide needs work. Showing the entire business model canvas is overkill.

</comment></comment><comment><USER24> very nice program

</comment><comment><USER25> Awesome... Nice job (:

</comment><comment><USER26> Fantastic idea, good job guys, keep going!!

</comment><comment><USER27> Buena suerte y todo el éxito del mundo!! =)

</comment><comment><USER28> Totally agree w/ the comments. It's a nice job! :D</comment>


Lem: A Common Lisp editor/IDE with high expansibility - <AUTHOR> https://github.com/cxxxr/lem <comment><USER2> I use Common Lisp professionally for work, and I love using Emacs and SLIME for editing Lisp. But over the past decade or so, I've also learned to maneuver around Emacs, and give it the attention it needs to become somewhat proficient at it.

In the case of others, I've observed much less patience. Patience maybe isn't even the right word; perhaps it's just an unwillingness to invest in something that doesn't really communicate an obvious return. Many of my coworkers, especially those who want to edit a little bit of Lisp but don't want to make it their life story, really wish there was a better editor.

Many of them Python programmers, or even technical folks with a non- programming background, really aren't sold on this whole Emacs thing to edit a weird language. Out of the box, you have to look up the plethora of cheat sheets and commands and figure out why GUI Emacs doesn't see your PATH and why changing the font doesn't stick and ....

They do appreciate the likes of Atom, PyCharm, Jupyter notebooks, etc. with big beautiful GUIs with big beautiful menus and slick websites and "out of the box" support for what they need to do. Pop-up suggestions, dedicated terminal windows, etc. "Obviously" Emacs can do these things, if not better and with more breadth, but it's all hidden behind The Model of Emacs Thinking (TM).

I really look forward to efforts like Lem improving. I hope they try to do at least one thing really well—editing and interacting with Lisp—and not 100 things poorly (e.g., trying to replace Python editors out of the gate). A great Lisp editor will be such a boon for the language, maybe as important to its rebirth a decade ago as Quicklisp was to it. Lisp is such a wonderful tool, and I want folks to see the great industrial uses it has. Selfishly, I also want to see more contributions to my own Lisp projects on GitHub. To the extent Lem can facilitate that, I'm entirely on board.

(If you're looking for some cool things to hack on in Lisp, try quilc [0], qvm [1], or maybe even Lem itself!)

[0] [https://github.com/rigetti/quilc](https://github.com/rigetti/quilc)

[1] [https://github.com/rigetti/qvm](https://github.com/rigetti/qvm)

<comment><USER3> I definitely fit into that second paragraph, and I appreciate you being careful to distinguish patience from being convinced of cost-benefit. I came to the conclusion after some pottering that it would be tough to make emacs nearly as good a python IDE as pycharm, not like a weekend's work it looked like a project in itself. It would again be a project in itself to make it as useful as jupyter for data-things. Someone has worked on embedding jupyter in emacs but it's a bit janky and you're then locked out from any extensions which will be written in javascript and expecting a DOM.

An investment in emacs seems to require a 10+ year time horizon, which means betting that it's going to grow and not decline, the numbers seem against that. I think what I really want is atom/light-table to get a lot better but the second died at birth and vscode is going to kill the first whilst having an uglier inner model that is less friendly to extensibility. I really wish Mr Granger had stuck with Light Table instead of running down a blind alley of VC money. There's a great quote that the threat to emacs is the browser, since it's a completely scriptable environment, I guess jupyter/light-table/atom embody that.

I still use spacemacs for running shells and editing files kind of ad-hoc.

<comment><USER4> Emacs + Jupyter integration got significantly better with the recent emacs- jupyter package [1], which, while young, is about as un-janky as any Elisp I've seen. I use this daily now for Julia/Python development.

The acs-jupter Org client augments Org's code cells with dynamic completion and inspection provided by the (potentially remote) kernel. The sessions can be managed per-subtree, enabling me to maintain various contexts within one Org file.

[1]: [https://github.com/dzop/emacs-jupyter](https://github.com/dzop/emacs- jupyter)

</comment></comment></comment><comment><USER5> I installed the stable (not Electron version) and kicked the tires. Looks like a fun project if you want turtles all the way down Common Lisp.

I admit that even for Common Lisp, I usually just use VSCode to edit with a separate repl (I always define a function (ll) that reloads the code I am working on so this is not inconvenient). Off topic but I now also mostly use VSCode for Haskell, Python, and Julia. Still love Emacs, just don't use it as my main driver anymore.

<comment><USER6> I'm surprised that emacs users and some vim users too are switching to VSCode. Assuming I am not RAM constrained (I have "only" 6 but my system never lags- I have 0 chromium engines on my system), what is your workflow and what does VSCode do better?

<comment><USER7> Sensible defaults are a big part of it for me. Using VSCode means that I spend very little time configuring the editor, or setting up extensions.

<comment><USER6> Why would you spend time doing anything? You just do it once and commit it to github? That's how my vimrc lives.

<comment><USER7> Does doing it once not take time? I usually get bored halfway through and switch to an editor that works properly out of the box.

In fact, of course, doing it once is a pipe dream. Everything with vim and emacs 90% works, and you can spend infinite amounts of time chasing the other 10%.

</comment></comment></comment></comment></comment><comment><USER8> I don't understand the goals of this project. What are these "tidy settings" they are talking about? And is having to install plugins in Emacs really such an obstacle? It would be great if the authors could elaborate a bit more about their motivation and vision.

<comment><USER9> Motivation: Emacs Lisp is not Common Lisp. It's cumbersome using Common Lisp for Emacs package development and cl.el is discouraged. Even not considering that simple fact, how we can use the massive Common Lisp ecosystem in a nice way? Sorry, I don't know how to do that in a simple way. Just no.

Beyond that Lem it is quite fast and there is the OpenGL [1] front as unofficial contribution. It could be embedded as a Lisp IDE inside of a game called Lisp Hacking Experience that was never made.

The amount of good reasons for doing that it can be enumerated by thinking about the common lisp ecosystem as I said earlier.

BTW, emacs is great but it not have good defaults enough for modern Common Lisp development, Lem it's awesome as default for Common Lisp ;). Not having any beginner friendly editor for Common Lisp it was one of the reasons that I teaching Lisp was so difficult.

Edit: Portacle is a good Emacs dist, but it is still emacs, so don't push the discussion with this in mind. It's pointless. And Portacle it's great in your own way ([https://portacle.github.io/](https://portacle.github.io/))

[1] [https://github.com/pupcraft/lem-opengl](https://github.com/pupcraft/lem- opengl)

<comment><USER10> This post is full of misinformation.

cl-lib.el is not discouraged, it's widely used by Emacs itself and pretty much every substantial Emacs Lisp library out there.

What's discouraged is using an older version, cl.el, at runtime [1] because it replaces existing Emacs Lisp functions and pollutes the namespace. Even that's ok to use at compile time though.

Lastly, cl-lib.el is not cumbersome to use.

[1] [https://www.gnu.org/software/emacs/manual/html_node/cl/Organ...](https://www.gnu.org/software/emacs/manual/html_node/cl/Organization.html#Organization)

<comment><USER11> Let me give it a try, from an abstract/Emacs point of view:

Emacs is good for Lisp development, but both "raw" Emacs itself and most of the packaged customization versions (Spacemacs, etc) are fairly 'opinionated' about Lisp, and that opinion usually falls close to: Lisp is great, but Common Lisp is a little/some/much too much, so our choices often lean away from CL's. (Lisp-1 vs. Lisp-2, dynamic vs. lexical scope, etc.) This means that you're customizing in a nearby language, but one that dislikes some of the things that you liked when you chose CL, so there's some impedance mismatch going on. That said, you can get a great CL dev environment from Emacs, but you'll want to install a bunch of add-ons first, probably including a non-Emacs lisp interpreter and a package to bridge Emacs and that other lisp. True fans of CL would really like a full-blown Emacs with real CL at its core, and periodically people try to make those (Hemlock, etc), but they usually don't catch on.

<comment><USER10> More misinformation here.

Emacs Lisp is a Lisp-2.

Emacs Lisp has lexical scope.

When writing code in Emacs, Emacs Lisp for all intents and purposes can be seen as a subset of Common Lisp, not an entirely different language like you present it to be.

Please try not to propagate this sort of misinformation again in the future. The things you claim are obviously wrong to anyone who has ever used Emacs Lisp, even once. Have you ever done that?

<comment><USER12> Please edit swipes and incivility out of your comments here, regardless of how misinformed someone else is. It's actually worse when you're right, because then you're discrediting the truth by associating it with rudeness.

There's an additional concern. As Lisp users ourselves, we remember how the CL culture was gutted by the wave of nastiness that rolled into it about 15 years ago. No trace of that is ok on Hacker News. Dismayingly, your comments have contained traces of it in the past as well as in this thread.

In fact, you have posted so many uncivil comments to HN already that we're going to ban you if you keep doing it. If you'd please read [https://news.ycombinator.com/newsguidelines.html](https://news.ycombinator.com/newsguidelines.html) and take the spirit of this site to heart from now on, we'd greatly appreciate it. This means erring on the side of respecting others, assuming good faith, and providing correct information to teach readers rather than humiliate fellow commenters.

You might also find these links helpful for getting the spirit of this site:

[https://news.ycombinator.com/newswelcome.html](https://news.ycombinator.com/newswelcome.html)

[https://news.ycombinator.com/hackernews.html](https://news.ycombinator.com/hackernews.html)

[http://www.paulgraham.com/trolls.html](http://www.paulgraham.com/trolls.html)

[http://www.paulgraham.com/hackernews.html](http://www.paulgraham.com/hackernews.html)

</comment></comment></comment></comment></comment></comment><comment><USER13> Nice work! Lem looks "Spartan" at first glimpse, the high expansibility however is a promising key for success. Anyone who truly loves Common Lisp has the opportunity to make Lem the best Lisp editor ever.

I am a long-term Emacs user but I think we really need an optional editor which can be extended in Common Lisp rather than Emacs Lisp. What I really like about Lem is the KISS principle ("Keep it simple, stupid") since Lem is based on curses which is good for portability.

I have no experience with Roswell. Is it possible to use QuickLisp packages? Or do you consider to switch from Roswell to quicklisp? That would make installation of Lem much easier!

<comment><USER14> Roswell and Quicklisp are two different things. Quicklisp takes care of downloading systems (what other languages tend to call packages) and makes them available to ASDF. Roswell and takes care of installing Common Lisp Implementations (think chruby + ruby-install). It also allows you to run lisp programs as scripts iirc.

FTW you don't need to install Roswell to try Lem, you can use cl-launch instead

<comment><USER15> FWIW you already can run lisp code as a script, at least under Linux. I've been doing the following for quite some time without issue:

\--- xx

#!/usr/bin/clisp

(format t "yup")

\---

and then on the command line:

> chmod a+x xx ; ./xx

yup

Caveat: You have to comment out the hashbang if you want to (LOAD 'xx) in the repl, or it will puke unceremoniously. It would be nice if repl devs allowed the LOAD function to simply treat it as a ; symbol since it wouldn't break anything and is more consistent with the cli behaviour.

I've only done this with clisp, so maybe other Lisp variants like sbcl et al already do this. YMMV.

EDIT: Realized the script came out all on one line. Fixed.

</comment></comment></comment><comment><USER16> If you want to create an nice FOSS IDE for Common Lisp, play around with Alegro and LispWorks, don't just try to redo Emacs + SLIME.

And take advantage of Common Lisp, no Electron needed.

</comment><comment><USER17> We use Allegro Common Lisp which has an interface[1] to emacs, and it's quite nice to use, minus several annoying bugs. Notably, gives you access to a REPL.

I just started working as a developer, and so far enjoying using it, despite not having experience with other languages in a professional capacity, or with large projects. The less my hands have to leave the keyboard the happier I am :).

I do use evil-mode, but I should probably get more comfortable with emacs keybindings as time goes on, especially since emacs has some useful keybindings in the context of s-expressions from what I recall.

[1]: [https://franz.com/support/documentation/10.1/doc/eli.htm](https://franz.com/support/documentation/10.1/doc/eli.htm)

</comment><comment><USER18> Neat. I use vim, but it's always nice to have options, especially ones that understand CL natively.

<comment><USER19> "I use vim"

Bold move, putting heresy right up front.

<comment><USER9> Totally, I don't think even that it's possible being productive with Common Lisp using vim. Just don't fit in my mind. I use vim to edit my /etc/fstab and works really wonderfully. But Common Lisp? D: maybe there is some magical stuff, unicorns plugins and so on...

<comment><USER20> I use emacs for Clojure but I've got two amazingly productive coworkers who use neovim. It is a non-issue for them.

</comment></comment></comment></comment><comment><USER21> Why all Lisp editors/IDE's look like Emacs?

<comment><USER22> Note that Emacs and GNU Emacs are different things. Emacs is a family of editors, which share some basic design principles (buffers, keymaps, modes, extended commands, ...).

Why do you think Lisp IDEs look like some Emacs? Because you happen to know them and haven't seen the other ones.

Many Lisp IDE's have an Emacs editor, but are not based on Emacs. For example the MIT Lisp Machine has Zmacs, but that's mostly used for editing text (and some functionality around it). Zmacs is also used as a component in a few other programs, like the Mail client. Other than that most Lisp Machine programs are neither based on Zmacs nor have a Zmacs UI. Examples: file browser, font editor, terminal, Lisp repl - none of that feels/looks like Emacs.

Interlisp-D / Medley from Xerox didn't look like Emacs at all.

The Allegro CL IDE doesn't look like Emacs.

LispWorks uses an Emacs written in Common Lisp, but for example does not share the buffer handling (in LispWorks buffers have their own windows all the time and they can't be changed). Additionally much of the LispWorks IDE is not based on an editor paradigm (inspectors, debugger, preference windows, ...).

Since 15 years most (not all) open source CL developers used GNU Emacs + SLIME as the IDE. SLIME replaced older tools for GNU Emacs. There wasn't much competition for SLIME - it also was relatively easy for Lisp programmers to add IDE features to an editor extensible in some Lisp dialect - it's much more difficult and more difficult to make Eclipse or Intellij a decent Lisp IDE, and the results so far are clunky. SLIME OTOH is quite usable as a Lisp IDE.

It would be about time to have a better Lisp IDE than GNU Emacs / SLIME - especially one which is more graphical. But then, we now have the javascript web and GUIs are again different.

<comment><USER21> I was referring to recent-ish IDEs, although from all those you mentioned the only that do not look like Emacs to me are Allegro CL and Xerox's. The rest might not have _exactly_ the same UI, but they still have a UI that looks very similar to Emacs.

As an example to the contrary, both the Allegro CL and DrRacket would be UIs that are not similar Emacs.

</comment></comment></comment><comment><USER23> Eh, call me cynical but I'm gonna join the rest and say that this looks like yet another attempt to reinvent Emacs that'll eventually just be left to die somewhere. If all this time reinventing Emacs poorly had been spent developing Emacs instead we could've had M-x flying-cars by now.

</comment><comment><USER10> One persistent problem I see in the Common Lisp (love the language!) space is the wide availability of crapware that not only doesn't bring something new to the table but is actively damaging to the community since it's diluting the set of good libraries and making it harder for new users to tell the wheat from the chaff. Lem is crapware. The problem it's supposed to solve, writing CL without configuring Emacs, is not a problem since there exists Portacle [1]. Lem is inferior to Emacs/SLIME/Sly in every way especially for writing Lisp. Lem has no future. But it exists and may act like a strange attractor to those who don't know better.

A question I'd really like to find the answer to: Why is there so much crapware for CL?. Why doesn't the community come together behind the few, really good, libraries but instead almost everyone goes out and does his own thing, the end result being an ocean of crap.

[1] [https://portacle.github.io/](https://portacle.github.io/)

<comment><USER22> The first Emacs was written on top of TECO.

The came young students who had access to a brand new Lisp Machine in the MIT AI Lab (thanks to the welcoming spirit of Marvin Minsky and others). They implemented EINE (EINE is not Emacs) and ZWEI (ZWEI was EINE initially) and then Zmacs. -> Weinreb and McMahon. Bernard Greenberg wrote an Emacs in Maclisp for Multics. Hemlock was written in Spice Lisp. From then on a bunch of editors were written in Lisp.

Don't let you be discouraged. Learning to write well architectured programs is best done by writing programs.

I applaud those who put their thoughts between nested parentheses and turn them into working code...

<comment><USER9> I agree with this comment totally, specially in this part:

> Don't let you be discouraged. > Learning to write well architectured > programs is best done by writing programs. > I applaud those who put their > thoughts between nested parentheses and turn them into working code...

We should appreciate jobs like lem! They are trying, thinking! And this HN section??? JUST COMPLAINING! What are you doing for helping? WTF.

<comment><USER14> Sorry to hijack the thread but congrats on Lem. It's nice to see how far it's progressed. You even have an XCB binding in there!

Lemonodor-fame is but a hack away!</comment></comment></comment></comment>


Why We Don't Need a DevOps Team - <AUTHOR> https://medium.com/seek-blog/platform-engineering-why-we-dont-need-a-devops-team-e88c8b97cc4f <comment><USER2> I find it frustrating that we're still having this conversation. I feel like it was common knowledge five years ago that DevOps was a cultural shift, and definitely not a toolset, not a team, not a position title. But I still see the anti-pattern all over the place.

How do we change this? And how do we prevent it from happening to similar movements in future? How do you get people to look at where the finger is pointing, and not the finger itself?

It reminds me of the first line of the Tao Te Ching: "The Tao that can be named is not the real Tao."</comment>


Ask HN: Will you consider using this Whatsapp tool? - <AUTHOR> Hello, I started to make a tool for managing and automating mine and my clients' whatsapp accounts 2-3 months ago and day by day I improved this tool according to my needs.
Right now, it's so easy to use. You will register from project website and it will give you a token and with that token you can send/listen messages and also you can still use your whatsapp account at your phone.
With using this project, I managed to create a whatsapp poll & whatsapp wall(streamed incoming media messages to a TV) &multi agent whatsapp support desk easily and every developer will be able to create tools (or bots) with this project.
I also consider integrating this project with services like IFTT&Zapier for extend my audience to power-users not only developers.
Here is a quick demo; https://www.youtube.com/watch?v=PIfAUozWNPU
Question is; I want to sell this to developers like 20$/mo do you think it's nice product?
Disclaimer: Please do not give legal advice. <comment><USER2> I watched the video. I still don't understand what it is clearly. I don't understand "why I should care" by which I mean how is using the potential product so much better than the alternatives that it offsets the risk of a dependency on Whatsapp's platform (and based on not wanting legal advice I suspect that there is risk involved in taking this kind of dependency on Whatsapp's platform).

Curious as to alternatives and their shortcomings.

<comment><AUTHOR> you are scanning a qr code from project's website or terminal, and boom you are able to create chat bots with your Whatsapp account.

I'm not using any open sourced and problematic libraries(which are replacing whatsapp client) like whatsapi&yowsup, I developed more secure, robost and undetectable method and want to create a product.

also what are the solutions did you mentioned?</comment></comment>


Show HN: Game Records: Social network for gamers - <AUTHOR> http://gamerecords.net <comment><AUTHOR> Hi,

I want to introduce you Game Records, a new social network for gamers. Currently we are on beta stage so it would be great if you can check it and share your comments here. Like or not please tell :)

</comment><comment><USER2> It's awesome site. Thanks :)</comment>


Safari will no longer trust certs valid for more than 13 months - <AUTHOR> https://www.theregister.co.uk/2020/02/20/apple_shorter_cert_lifetime/ <comment><USER2> There are two mutually exclusive views of the web. As a set of protocols to allow individual humans to share information about things they love and the web as a set of protocols to make a living.

There are real reasons for the for-profit web to want to limited cert lifetimes since revocation doesn't really work in practice. In terms of browser dev the two views are mutually exclusive and the one that funds the coders gets it's way. Especially with the W3C marginalized and a mix of corporations and corporate-centric standards groups running things now. Expect to eventually be unable to host a visitable or indexable website without relying on at least one third party service in the near future.

<comment><USER3> With Let's Encrypt it's cheaper than ever to host a personal website over HTTPS with a certificate that updates itself.

Due to Let's Encrypt, free hosting services like Netlify or GitHub Pages are now providing HTTPS certificates and installing it on your own server is pretty painless, if you're into managing your own server. And if your hosting provider doesn't support Let's Encrypt, you can always put Cloudflare in front of it.

So I don't really understand what you're talking about, when the price and ongoing maintenance of HTTPS certificates has gone significantly down for hobbyists.

<comment><USER4> > _Let 's Encrypt [...] Netlify [...] GitHub Pages [...] your hosting provider > [...] Cloudflare_

Those are exactly the kind of third-party services the GP was talking about.

> _if you 're into managing your own server_

One of the core advantages of having a personal server has always been that you can keep it entirely off the internet and run it without _any_ involvement of third-party services. That is not anymore possible. Like, I now need to purchase a domain name and set up infrastructure to fulfill Let's Encrypt's challanges, just so I can serve a page on my LAN.

<comment><USER5> You can use HTTP instead of HTTPS or you can use a self-signed cert.

<comment><USER4> Often, this doesn't even work for small projects:

\- HTTP have no access to a significant part of web APIs added in the last years - and they will be blocked from _all_ APIs that are being added in the future.

\- Self-signed certs show security warnings that are deliberately confusion and discouraging to click through and will likely become even more so in the future. Show those to other people is no option.

<comment><USER6> In my opinion this doesn't fall under the "it's only on my LAN and a super small project" category. If you LAN is a company then you should be able to deploy a custom CA to your clients and sign your certs. If it's only your small side project you personally work on, then just trusting the cert locally works out too. If people don't want to use third party providers, they have to do some of the work on their own. That's nothing new (at least to me).

<comment><USER4> A small, personal project does not mean that the developer is the only person that uses it. Servers can also be used by friends, family, roommates, etc for which installing and managing custom CAs is a hassle.

I do agree that using Self-signed certs and clicking through security warnings is possible - however, is being made deliberately tedious (e.g. Chrome will forget that you accepted the cert after a while). It also seems to me that this part is actively discouraged by browser vendors, so I'm honestly not sure how long it will stay open.

Self-signed certificates are also unpredictable to do API requests to because no accept UI is shown for such requests.

> _That 's nothing new (at least to me)._

It absolutely is. With HTTP, you could simply run a local web server and have everything interested point their browser towards it - and everything worked. This is not possible anymore unless you want to make recurring payments for a domain and accept that you need an internet connection.

<comment><USER7> And this is exactly why SSL everywhere is a really, really, bad idea. (Plus the problems of IoT server certs, mentioned above...)

<comment><USER4> I understand the rationale behind https-everywhere and I believe it's absolutely necessary for the web at large. The problem of network attackers is certainly real.

However, a side-effect (intentional or not) is that the web is turned into a sort of app store: Either you belong to the platform or you don't, and whether or not you do is decided by third parties. (Who, btw, are not even bound by any kind of public mandate - they are simply private, profit-driven companies)

I also don't think the stated security advantages always make sense: Let's Encrypt will serve network attackers just as easily as legitimate customers. Meanwhile it will lead to a lot of stuff being exposed on the internet than would be necessary otherwise. We also force devices that simply should expose a local web interface to have a cloud service. I don't see how this makes anything more secure.

I guess what I'd want is simply a way to designate a device as "trusted" locally, without depending on third-party services, internet connectivity or anything else and without anything expiring. A way that should be encouraged to be used by non-techical users as well.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER8> Anybody knows why Safari on iOS will reject using self-signed certificates for WebSocket connections? (doesn't happen on desktop)

This is a major annoyance since it is the _only_ browser that does this and won't work with "wss://" URIs even after accepting the mandatory certificate exception. Accessing the page rightfully shows a warning on all browsers, to which the user can click on "Continue" or similar, to ignore this and start the demo, except if they try with iOS (this is for simple one-off tutorials or demos [1], so maintaining good certs _or_ requesting users to install a custom root CA in their devices is out of the question).

I know, this seems like a StackOverflow question... but the only 100% relevant one I found [2] didn't get much love, so I thought maybe someone at HN knows more about this

[1]: [https://github.com/Kurento/kurento-demos- js/tree/master/play...](https://github.com/Kurento/kurento-demos- js/tree/master/player2many)

[2]: [https://stackoverflow.com/questions/36741972/using-a-self- si...](https://stackoverflow.com/questions/36741972/using-a-self-signed- certificate-with-safari-and-websockets-osx-ios)

<comment><USER9> Apple recently (last fall) introduced a change that rejects all certificates that are valid for more than two years, whether they're public or private. I would double-check whether the self-signed certificates are valid for longer (many default self-sign processes make ten-year certs, for instance). Failing that, you may have to create a proper private PKI and get users to install the CA, or else use something like Let's Encrypt for certs.

<comment><USER8> Thanks! you gave me one thing to check. The certs are indeed made for 10 years validity, the idea being that they should just make the demo work for a long time, even if it is with a certificate warning.

I don't think it's worth the effort of setting up all the automatic renewal process with Let's Encrypt for what amounts to a quick static code example... so in principle I wanted to avoid having to set that up.

The contents of _this_ article means that soon this 2-year maximum will become a 13-month maximum, right?

Is there any way to create these specific-purpose certs with some kind of "private use" or "development use" flag that allows not having to re-create them so soon? 13 months looks too short of a time period, I'm afraid nobody will remember to refresh the fake certs and the demos will break... for really no good reason (related to the code itself)

<comment><USER9> No, Apple was clear that this change (the 13-month limit) only affects public certificates, so internal private PKIs and self-signed certificates retain the two-year limit from before. I _think_ that that two-year limit extends to every certificate used for TLS in the system, so there's no way to get around it by manually trusting the certificate or CA chain (there's no 'development use' flag on certs), but that bears testing.

</comment></comment></comment></comment><comment><USER10> Apple is the reason I just switched a handful of certificates from Let's Encrypt to basic 2 year DV.

To support Apple Pay on the web, you have to go to your developer account on the Apple website, and under certificates generate a custom ASN.1 authentication file and upload it to the `/.well-known/` folder on your domain. Once uploaded, you have to click a "Verify" link, to check the file and mark the domain as Apple Pay approved. The issue is the verification only lasts as long as the certificate expiration, and if a new certificate is installed, you have to re-verify the domain with a newly generated authentication file, _for each domain_. A fresh certificate with an old authentication file does not work.

This means if using Let's Encrypt, you have to manually step through the verification process for each of your production, staging and development environments every three months. There doesn't appear to be any automated way to handle this.

After two cycles of this I opted to purchase 2-year certificates just to save the hassle of re-authenticating my web environments on a rolling basis by hand.

This announcement just means more frequent manual processes once again. What a pain.

<comment><USER11> There is some argument for this kind of certificate pinning (though I'm honestly not sold on the idea), but I think that this example is a further argument for scriptable certificate renewal. Most ACME clients allow you to run scripts after the certificate is renewed, so you could (in principle) trigger a script that does this Apple-specific verification process for you (maybe you could even trigger the "verify" button click by messing around with cURL -- though it'd be pretty annoying for there to be no API for this process).

By manually getting 2-year certificates you're setting yourself up to forget part of the renewal process. This was the main argument behind Let's Encrypt having such short expiration windows -- it encourages people to script their entire deployments.

<comment><USER10> I think this is an argument that while a certain group of server administrators and security professionals love ACME, it still has a number of kinks to work out.

In my case I'm not really setting myself up to forget about the renewal process as I have a script to generate the key and CSR and an ansible playbook to update the cert once sent to me. Certificate vendors are more than happy to email you to remind you of an upcoming renewal, in just the same way Let's Encrypt does.

On a side note, trying to script out the proper setup/migration of Let's Encrypt is WAY more involved and fraught with mistakes than a simple certificate upload. The failure case is that the initial certificate issuance succeeds but since the initial setup needs to happen before SSL is configured and working with Nginx, you can't use the same config before and after the initial setup. Thus you need to have two separate Nginx configs and switch them, or you have to use standalone for the initial issuance and webroot for renewals. Both of these are far easier to mess up than uploading a certificate.

I've set up more than 10 different servers with Let's Encrypt and I don't think a single one has just worked. I think in every case something got messed up along the way, and you only find out about it 70 days later with the renewal email, IF you are the admin email on the LE account.

Don't get me wrong, I think there are great things about Let's Encrypt, but it has plenty of thorns to deal with. I'm glad we haven't all been forced into three month renewals by the CAB forum (since the certificate vendors have a say and they got feedback from customers before agreeing). I am fairly annoyed that Apple decided to unilaterally change the rules when they were already part of an organization that deals with this topic. I can only imagine browser vendors moving forward will have little to no concern for site/server administrators and how their changes are affecting things.

As it stands now, we are at 400 day certificate lifetime, which means a bad actor can only impersonate for a year, in the name of revocation being performance prohibitive. This is effectively the same as three years from a users perspective. The only meaningful change would be a lifetime of something like a week or a day, but I shudder to think of all the ways that will fail spectacularly.

</comment></comment></comment><comment><USER12> I have my own mini-CA for internal stuff, built using the xca[0] tool with certificates and private keys distributed manually. I usually make the keys valid for two years so that I don't have to renew and redistribute very often. Most of this started as a way to learn how this stuff works, but it's now turned into a "production" thing as I've started using this to issue user certificates for VPN authentication.

Is there any tool that I can use to help automate this in a reasonable manner?

Ideally, I'd love to see a web version of xca that supports ACME with some controls on how ACME certificates get issued. Bonus points for supporting OCSP as distribution of CRLs is another upcoming pain point.

[0] [https://hohnstaedt.de/xca/](https://hohnstaedt.de/xca/)

<comment><USER13> If you're moving Private Keys you are Doing It Wrong. This is very common in VPN setups (and S/MIME) but still a terrible idea and worth taking the time to figure out how you'll make sure you don't do this.

<comment><USER12> I'm definitely open to learning how to do things better, and I have no doubt that some of what I'm doing is wrong - after all, this whole thing started as a homelab-turned-homeprod learning experience.

I think the proper way to do certs is to have the server (Web, VPN, whatever) create a certificate signing request and private key on the server, send the signing request to the CA to sign it, and then install the resulting signed cert on the server. Is this correct?

What I'm finding in some cases is that there are cases where this just won't work. For example, my QNAP NAS allows me to either create a self-signed certificate (I don't want this, I want it signed by my CA), get one from Let's Encrypt (same issue), or upload certificate, private key, and optional intermediate CA certificate files (and we're back to moving private keys). This is a limitation of QNAP's GUI for sure, but it's not unique to QNAP.

Similarly, I'm not sure how I'd generate the certificate plus private key on an iOS device and submit it for signing (the VPN scenario). This one particularly bothers me because the .mobileconfig file ends up being the key to the castle. Ideally I'd like the client to be authenticated with both a user-specific certificate and EAP, but I don't think iOS supports this. I haven't quite gone very far down this rabbit hole, so it's possible that I'm missing something.

When I finally secure my internal web server (which acts as a reverse proxy for all of my internal services), I'll try the CSR approach for the learning experience. This approach should also work fine on my VPN server.

<comment><USER13> > I think the proper way to do certs is to have the server (Web, VPN, > whatever) create a certificate signing request and private key on the > server, send the signing request to the CA to sign it, and then install the > resulting signed cert on the server. Is this correct?

Yes. The CSR is public information so it's fine to send that somewhere. "Sign it" [the CSR] is a phrase that doesn't entirely reflect what's happening with the relationship between a CSR and Certificate, experts know it's technically wrong but they say it anyway, so don't sweat it but it's probably misleading.

I will try to circle back to see if I have any suggestions for your specific scenarios later.

<comment><USER12> Thanks!

I'm going to try the CSR route the next time I have to do this and see how that works out. xca seems to handle CSRs easily, so doing this less-wrong should work out fine.

I'm not too concerned about the QNAP scenario - it's consumer gear, so I expect it to lean more towards doing things easily over doing things correctly. The iOS scenario is much more interesting to me since this is something that's more applicable in the real world.

</comment></comment></comment></comment></comment><comment><USER14> I develop for Apple platforms, and it's absolutely mind-boggling how frequently and regularly they break your code for no tangible benefit.

Hopefully their influence doesn't spread to the web too.

<comment><USER15> There is a tangible benefit. For users.

64-bit only, Project Catalyst, BitCode, HTTPS only connections etc are examples of initiatives which definitely has caused pain to developers but has immensely benefited users as a whole. And if you don't passionately care about users then frankly find another platform to develop on.

<comment><USER16> >64-bit only

how has that benefitted the user? Directly and measureably, no "it's 0.3% faster now" excuses.

<comment><USER17> Not having to load both 32-bit and 64-bit libraries into memory is an efficiency (and battery life) improvement on the system as a whole.

<comment><USER16> That would fall into the "it's 0.3% faster now" category.

</comment></comment></comment></comment></comment><comment><USER18> No joint announcement with other industry 'leaders' like Google and Microsoft? What is their stance on this? Will they be making similar changes to Chrome/Edge? And Mozilla? And maybe I am wrong but compromised certs are game over very soon aren't they? Reducing their lifetime to 'just' a year is still plenty of time to do enough damage seemingly, so what exactly does this high- handed change bring to the table? Another reason stated that it will keep the cert management folks busy and alert also sounds like grasping at straws to prop up the decision. I wonder what the entire reasons are...

<comment><USER19> The goal is to promote automation and continue lowering certificate lifetimes as operations get better. This ultimately will allow for lifetimes short enough to be useful.

As for the other browsers, Google originally proposed SC22 ([https://cabforum.org/pipermail/servercert- wg/2019-August/000...](https://cabforum.org/pipermail/servercert- wg/2019-August/000894.html)) last year and all the browsers voted for it. CAs voted it down at the time but there were rumblings via various back channels that several major CAs actually wanted the ballot to pass but for political reasons could not publicly support it.

So while Apple is acting "unilaterally" here, there is universal support among browser makers and tepid support from CAs. You should expect Google and Mozilla to follow suit in the next 6-12 months.

<comment><USER20> How will that automation verify that certificate is issued to the legal owner of the web site and not a hacker? Are the challenges used by Let's Encrypt secure? For me, automating certificate issuance will lead to less and less verification, to the point where having a valid certificate will become meaningless.

EDIT: to clarify - there are two bad things about Let's Encrypt:

1\. It's automated

2\. It's free

The fact that it's automated results in less human intervention along the way, which on one hand lowers costs, on the other hand makes it detecting scams harder (unless they deploy some really Machine Learning that detects frauds).

The fact that it's free means that there's no credit card number or other info that would help identify actual person that requested certificate issuance.

Together those things make things less secure, not more.

EDIT 2: Both types of Let's Encrypt challenges look like pushing down the responsibility to either web server owner or DNS service. Maybe that's a good thing, since at least there's one fewer party that can screw things up.

<comment><USER21> I think you may not be very familiar with Let's Encrypt's challenges. Allow me to briefly explain the gist of them:

The two most common challenges are an http challenge, and a DNS challenge. The http challenge gives you a response code to host as a file on the domain during the validation period. This challenge is, for all practical purposes, random, and cannot be guessed. Then, after your script tells Let's Encrypt that the response to its challenge is available and up-to-date, Let's Encrypt performs an http GET request to retrieve that response, and checks to ensure it is exactly what the script provided. Only then does it proceed with signing your CSR and giving you a valid certificate.

This requires (at least temporarily) a web server running on port 80 at the domain in question, and in order to break it you would need to be able to effectively either hijack the A record for the domain as read by Let's Encrypt, or to break into the web server to properly issue a certificate that one then steals. Impossible? Probably not. Impractical? Very.

DNS challenge is even more secure, in my opinion, as it works the same but the response code is stored in a TXT record for Let's Encrypt to validate. In order to break this you would need control of the DNS servers.

So, to put it rather simply, >Are the challenges used by Let's Encrypt secure? Yes, so long as you trust your DNS and web servers not to be compromised. And if they are, it's frankly game over anyway.

Now let's contrast this with, for instance, getting a multi-year certificate from the likes of Verisign or similar: this (as far as I am aware) requires manual interaction, which can at least theoretically allow for human error, of which there are many chances.

Additionally, many more traditional CAs will let an inexperienced user have the CA generate the private key and then transmit it to the user. This opens up a LOT of dangerous possibilities, as now this private key is being saved and moved around, and could easily be missed and left on the workstation used to perform the work. Or a MitM attack could even snatch it in transit.

Honestly, I don't think there is much (if any) point in still using manual verification. The human aspect of it also opens up chances for forgery, and so on.

Let's Encrypt's challenges are specifically designed to be difficult or impossible to hijack, and so far as I understand it the private key should never leave the server it will remain on.

So again, to answer your question succinctly and to the best of my knowledge: yes, the challenges used by Let's Encrypt are most certainly secure.

<comment><USER4> _> DNS challenge is even more secure, in my opinion, as it works the same but the response code is stored in a TXT record for Let's Encrypt to validate. In order to break this you would need control of the DNS servers.

> Now let's contrast this with, for instance, getting a multi-year certificate > from the likes of Verisign or similar: this (as far as I am aware) requires > manual interaction, which can at least theoretically allow for human error, > of which there are many chances._

What I've never understood is how this doesn't ultimately just shift the security risk to my DNS registrar.

Instead of social-engineering the CA to give me a cert, I have to social- engineer the registrar to store a TXT record. I don't see why one should be significantly harder than the other.

 _> Additionally, many more traditional CAs will let an inexperienced user have the CA generate the private key and then transmit it to the user. This opens up a LOT of dangerous possibilities, as now this private key is being saved and moved around, and could easily be missed and left on the workstation used to perform the work. Or a MitM attack could even snatch it in transit._

Again, it's harder for a rogue CA to abuse my certificate - but instead, a rogue registrar could now easily manipulate my DNS record and receive a valid cert of its own.

<comment><USER9> > What I've never understood is how this doesn't ultimately just shift the > security risk to my DNS registrar. > Instead of social-engineering the CA to > give me a cert, I have to social-engineer the registrar to store a TXT > record. I don't see why one should be significantly harder than the other.

Rogue registrars aren't necessary: one can simply attack the registrar or interfere with the DNS traffic. These attacks have already been seen in the wild and are continuing today: check out info on DNSpionage ([https://blog.talosintelligence.com/2019/04/dnspionage- brings...](https://blog.talosintelligence.com/2019/04/dnspionage-brings-out- karkoff.html)) and Sea Turtle ([https://blog.talosintelligence.com/2019/04/seaturtle.html](https://blog.talosintelligence.com/2019/04/seaturtle.html)) attacks.

Meanwhile, Let's Encrypt has been making some interesting changes. For instance, they just introduced multi-perspective challenges ([https://letsencrypt.org/2020/02/19/multi-perspective- validat...](https://letsencrypt.org/2020/02/19/multi-perspective- validation.html)) in which they submit multiple challenges to the user from different network paths. Attackers hijacking network paths to interfere with challenges must then intercept all possible paths to a client, which is much harder.

That said, I'm not a fan of devolving our certificate validation to DNS--it's like building a castle on Jello. It wasn't designed to be a security-first protocol, and it's definitely showing its age.

</comment></comment></comment></comment></comment></comment><comment><USER22> IMHO, expiration dates on certificates are and have always been the Wrong Thing. The Right Thing is to have the certificate contain a time stamp of when it was issued. The client should decide whether the certificate is still trustworthy. The cert can contain a recommended expiration date, but the dispositive information should be the issue date.

<comment><USER23> Can someone chime in with the original intended purpose of the expiration date?

The one that I can imagine (without research) is that the issuer knows the quality of their own security practices, and if they says that a certificate will expire by X date, they are saying that they can't guarantee that they will still be the only person with the secret key after that point.

Any other explanation?

<comment><USER24> > the issuer [...] are saying that they can't guarantee that they will still > be the only person with the secret key after that point.

It's not quite clear what you mean here.

The issuer should _never_ have the private key for the end-entity cert (the one representing the domain or whatever). Only the owner should have the private key.

EDIT: Hmm, according to another comment here, some CAs will offer to generate both halves of the keypair for the end user. Yikes.

If you are talking about the CA's own private key...if that _ever_ leaks, then _no_ certificates signed by it should ever be trusted again; expiration date has no relevance here.

<comment><USER13> > EDIT: Hmm, according to another comment here, some CAs will offer to > generate both halves of the keypair for the end user. Yikes.

I wasn't able to find this comment, but perhaps I didn't look hard enough? EDIT: Wait, I think I found it. I will reply there.

In the Web PKI this is prohibited _but_ there are or at least were resellers who'd offer this service to their customers. You should not use this service of course, and some CAs have pledged to tell their resellers not to offer it.

In S/MIME it's more common because often the end user is both technically unsophisticated and not given real control over their client in order to mint their own keys anyway. But S/MIME is... probably not important, certainly it isn't what Apple's change is about.

</comment></comment></comment></comment><comment><USER25> While I agree that it is better from a security perspective not to issue long lived certificate and that automation would be best, I dislike the fact that the subdomain of any certificate I issue becomes public due to Google's certificate transparency project.

By making every subdomain public, it makes the job easier for any attacker wanting to try and find smaller servers to target. It's not that I believe in security through obscurity but besides making sure all servers are as secure as they can be, I do believe in not making the job easier for adversaries.

So, instead I use wildcard certificates, and for this automation gets much more annoying, you need to use DNS to validate it (route 53 or similar does provide an api that can be used) and then I'm not sure if I'm confortable having each server generate their own wildcard certificate, leading to 100s of wildcard certificates...

This is why I currently use old style 1 year wildcard certificate which gets updated through chef but I'm really not sure if this is the best solution or not.

<comment><USER26> Without certificate transparency how do you know nobody has issued a certificate for your server? Surely that's a far higher risk than knowing a domain?

<comment><USER25> oh, I completely agree that certificate transparency is beneficial for that and we have an alert setup. But, that still leaves me not wanting to leak every single subdomain we use internally. Hence using wildcard certificates.

<comment><USER13> CT didn't change this for bad guys. If you're a bad guy (or a neutral researcher with a budget for the data) you can buy what's called "Passive DNS". Several suppliers will give you a list of DNS requests and their answers, the identifying information for who made the requests is elided so it's not PII but it has the same effect of making the fact servername.example.com exists in effect public information.

Even if you are unusual in actually having machines named cy23hdc9.example.com not exchange2016.example.com then the existence of this service means you need to stop assuming nobody knows these names. Anybody who cares knows them.

<comment><USER4> Yes, which is why you used to be able to have fully internal domains that are served by an internal DNS server and are never seen on the public internet.

<comment><USER9> You can still have this: it's called 'split-horizon' or 'split-brain' DNS. It can be tough to set up and maintain for large DNS environments, but not /that/ difficult even at that level. If you do this and you don't want those names in the public CT records, though, you have to implement a private internal PKI for those servers so they're not getting public certs. Or use a wildcard, which carries its own significant security risks.

<comment><USER4> > _you have to implement a private internal PKI for those servers so they 're > not getting public certs_

This would also involve setting up a custom CA and distributing your CA cert to all machines that should be able to access the page. Good luck with that!

All of this is a ridiculous amount of effort to set up and maintain. It's a lot easier to just make the internal domains accessible to the internet and be done with it.

The effect being that networks are being nudged into exposing a lot more surface to the internet - and this somehow in the name of more security.

<comment><USER9> It's not terribly painful to do if you have central management (e.g. you can push them out through a GPO or MDM system). For small businesses, however, I totally agree it's a pain in the neck: the school my wife teaches at would have a devil of a time doing it with their current IT staff workload, and they'd still have issues with unmanaged devices. And all that's to say nothing of the ticking time-bomb that occurs when you set up your own PKI--good luck remembering to replace that root CA ten years down the line when it explodes.

The cynical part of me says that certain companies might be very interested in the search possibilities gained from exposing internal networks to the Internet, and the increasing lock-in that occurs when you make your systems dependent on their public CA instead of your own private one. But perhaps that's just the tinfoil-hat talking. :)

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER27> I understand the reasons behind wanting to shorten certificate validity periods, but CA or root certificates often have expiration periods far into the future. What's the argument for this? Ease of use? Historical reasons?

<comment><USER28> It's not easy to (at least this was the case until a few years ago) to ship updates to an old device (think Android 4.x or Windows XP; even worse for embedded systems). Hence to avoid the devices become useless bricks even if otherwise fully functional, root certs need to have more than a decade cert validity at minimum. (That's my personal theory, I'm not in the industry).

<comment><USER29> I think the industry is very much trying to push for the exact opposite of that, with things like planned obolescence to ensure you keep consuming their latest products.

</comment></comment></comment><comment><USER30> Just look at the state of the "modern" internet with it's certification wars, 2-level auth, Google SMTP gatekeeping, mandatory HTTPS, Letsencrypt v2 & certbot renewal fsck-ups. What hope in hell does the ordinary user have of navigating all this? Do we all now need to be experienced sysadmins just to use the internet?

</comment><comment><USER31> Apple Drops SSL/HTTPS Bomb - Forget Long Certificates

[https://keychest.net/stories/apple-drops-sslhttps-bomb- forge...](https://keychest.net/stories/apple-drops-sslhttps-bomb-forget-long- certificates)

</comment><comment><USER32> Google doesnt trust my password for a gmail account that I last used 6 months ago (I had to also provide one my previous password to be able to login). It is getting ridiculous...

Now I gotta keep an history of passwords, just for Google...

</comment><comment><USER33> Apple's browser is already called "the New Internet Explorer":

[https://fabiofranchino.com/blog/css-height-parent-flex- safar...](https://fabiofranchino.com/blog/css-height-parent-flex-safari- issue/)

[https://dev.to/nektro/safari-is-the-new-internet- explorer-1d...](https://dev.to/nektro/safari-is-the-new-internet- explorer-1df0)

[https://arstechnica.com/information-technology/2015/06/op- ed...](https://arstechnica.com/information-technology/2015/06/op-ed-safari-is- the-new-internet-explorer/)

... and millions similar articles

I developed widgets for web developers and I had to change it to stop using the 'fixed' positioning anywhere, because iOS is the only browser that interpret it differently on all touch enabled devices. They have many other issues as well. I have to spend half of my time to fix their buggy browser!!!!!!!!! Not even the old internet explorer causes that many issues as safari.

They torpedoed progressive web apps and many important web standards. Why? Just because they want you to use their apple store, where they can take 30% from every transaction without doing anything.

I hope Apple will go bankrupt and stop hurting the web community as they successfully did in the past years.

</comment><comment><USER16> Safari market share ... so who cares.

I am not talking about mobile usage.

</comment><comment> X-Istence I posted about this a couple of days ago: [https://news.ycombinator.com/item?id=22373673](https://news.ycombinator.com/item?id=22373673) didn't get much traction then :-(

</comment><comment><USER34> Is this an early April fool article?

<comment><USER35> What do you find strange about this?

<comment><USER34> That the CAs are happily still selling 2yr TTL certs?

</comment></comment></comment><comment><USER36> I don't think certificates are a good solution for most websites. Instead have the browser store the public key first time you visit the site. Then ask the user every time it changes, like with SSH. Also browser should send their public key to the server! So that we don't have to come up with a new password for every damn site.

<comment><USER37> >Instead have the browser store the public key first time you visit the site. Then ask the user every time it changes, like with SSH.

The vast majority of users will not understand this. Also let's say you go to a site one day, and you get a prompt that their certificate has changed. Is this legit? How can you know?

>browser should send their public key to the server!

This already exists (HTTPS Client Certificates) but it's a huge pain in the ass so it's barely ever used. When it is used, it's generally within a controlled corporate environment.

<comment><USER36> There could still be a trust chain. But most websites don't need it, just like most websites only use the basic level of certification today, all they really want is encryption. (or the green padlock :P)

Client certificates has kinda been deprecated by browsers. Which is why it's such a PITA. Also handling signing certificates by itself is a PITA. But most website's wouldn't need signing, just encryption.

Automatic SSL certificate signing is not that secure, if an attacker would be able to mess with DNS, or access the HTTP server, they could also create a fake certificate via Letsencrypt. Or if the attacker has access to the client, they could sneak in a root certificate. Most nation states and ISP (those who would like to spy on it's citizen) already have root certificates. All that SSL certificates do is to create extra work for site maintainers. We can have encryption without certificates. If you would for example side-load a list of public keys for the main sites you visit, that would be much more secure then SSL certificates are today.</comment></comment></comment>


How to Beat High Airfares (2011) - <AUTHOR> http://www.nytimes.com/2011/05/08/magazine/mag-08subversion-t.html?_r=1 <comment><USER2> Part of my job is to prevent this. We are very good at cancelling your ticket based on airline rules if we know you wont get on a plane based on your other flights. Airlines ban/fine travel agents (and sometimes passengers) that abuse their rules.

<comment><USER3> You're not doing a very good job.

Almost all my flights these days use a 3X to reduce the YQ.

The economist does a fairly good job at explaining it. [http://www.economist.com/blogs/gulliver/2013/11/fuel- dumping](http://www.economist.com/blogs/gulliver/2013/11/fuel-dumping)

<comment><USER4> Could you tell us some more about how you do it?

<comment><USER5> _Experienced dumpers scorn novices seeking guidance, unless the newcomers can offer hot new 3Xs in exchange._

</comment></comment></comment></comment><comment><USER6> According to this story [1], in 2012 airlines made just $0.37 per passenger trip. So, while I think the inefficient pricing is in need of repair, to say that prices are too high, is unfortunately not true. I hate paying for transcontinental flights as much as the next guy, but what other way can you cover 3000 miles that cheaply and quickly?

[1] [http://online.wsj.com/articles/peter-thiel-competition-is- fo...](http://online.wsj.com/articles/peter-thiel-competition-is-for- losers-1410535536)

<comment><USER7> Is that because of pricing or because of company structure/setup though? Ryanair is currently predicting 510M profit on 81M trips in Europe for 2014.

Not saying they are a model company in any way (the main thing I disagree with is some of their employee treatment), but they are certainly proving that it is possible to operate a profitable airline with low prices and high quality.

<comment><USER8> only $6.30 profit per trip and that's the best example of a profitable airline, crazy

<comment><USER7> That is on about 3-4B revenue or so though, so its actually a pretty good profit margin.

<comment><USER8> That would be only $49 in revenue per trip, seems low.

<comment><USER9> When you put it in those terms it seems almost insane. How can any company operate on such low margins? I mean, yes, the "Walmart model" is the answer, but it seems like they could go under very easily if hit by something unexpected.

<comment><USER10> > it seems like they could go under very easily if hit by something unexpected

They do. [http://en.wikipedia.org/wiki/Airline_bankruptcies_in_the_Uni...](http://en.wikipedia.org/wiki/Airline_bankruptcies_in_the_United_States)

</comment></comment></comment></comment></comment></comment></comment><comment><USER11> A risk of this is that the airline is only required to get you to the actual destination your purchased. If your flight is cancelled, they could re-book you with a routing that doesn't fly through your intended destination.

<comment><USER12> They should start doing that, or something similar. Say you book a flight from city A to city B, but you really intend to drop off at the place C which is the middle-stop. Airlines could every now and then switch the route to go through a different city D without announcing it in advance. Getting stuck in a different city at random would quickly drive the point home to cheaters.

<comment><USER9> That's unlikely simply because it would upset a lot of people, non-cheaters, as it both alters their itinerary but also alters the total travel time (e.g. 8 hrs instead of 6 hrs).

Plus that isn't really how aircraft travel works, it isn't a single aircraft which travels from A to B to C, it is a connection which only exists because aircraft A and B land at the same airport within 30-60 minutes of one another.

Now everyone understands if there is an aircraft issue/emergency and the airline needs to re-route you. But if they started making a random habit of it just for "fun" (to catch less than 0.1% of their customers) people would get upset very quickly.

<comment><USER13> It would also wreak havoc with the airlines' routing system. The reason this hack works is because airlines try to route connecting flights through hub cities so that many different passengers can get to many different cities; if they routed the connection through a different city, suddenly all the _other_ passengers would find themselves with no way to get to a final destination.

</comment></comment></comment></comment><comment><USER14> The article is touting hidden city ticketing. While this is still a valid strategy, one needs to be careful when employing it as the airlines hate this behavior. It's not against the law but (I think) it is against their contract of carriage.

Better (and less dodgy) advice would be to follow these websites:

[http://www.theflightdeal.com/](http://www.theflightdeal.com/) (my current favorite)

[http://faredealalert.com/](http://faredealalert.com/)

[http://www.airfarewatchdog.com/](http://www.airfarewatchdog.com/)

Set up an IFTTT alert on the RSS feed for your home airport and/or desired destination and jump on it when you get the notification.

</comment><comment><USER15> Here's a site that lets you search for these flights: [https://skiplagged.com/](https://skiplagged.com/)

I've used it many times, usually saving around 50% on flights. I never check bags anyway, so it works out well.

<comment><USER9> You can use a similar technique to get ultra-cheap First/Business class tickets to places like Europe.

You book a flight to some poorer European country, like Poland for one example, it will have a stop-over in either Paris or London, you then disembark there.

The tickets will be partly based on the cost of living in the destination (Poland) so be significantly cheaper than a ticket to London or Paris direct in those classes (i.e. same exact aircraft, same route, same class, but cheaper).

</comment></comment><comment><USER16> There was a great Stack post on this a while ago. Basically it always boils down to booking early, really, that's how you get those cheap flights. The "book a few weeks before" option is bunk.

For most of us Europeans, jumping off at a stopover isn't an option, although it _is_ possible to do this on trains sometimes (and actually it's very legal, you're entitled to break your journey at a valid calling point).

[https://travel.stackexchange.com/questions/2952/flight- ticke...](https://travel.stackexchange.com/questions/2952/flight-tickets-buy- two-weeks-before-even-during-holiday-seasons)

<comment><USER17> In the UK, you can break your rail journey on the flexible ticket types, but not on Advance fares.

So you can either get a good deal by booking in advance, _or_ by breaking a cheaper, longer journey - but not both.

<comment><USER16> Not to mention that you should always split tickets if possible, particularly if you change service providers. That and avoid London and First Great Western; their ticket prices are obscene.

</comment></comment></comment><comment><USER18> If you really want to beat high airfare, stop buying tickets and figure out how to accrue frequent flyer miles at the lowest rate. BoardingArea.com is a good resource. Few years back, people figured out US Mint was selling gold $1 coins at cost + free shipping, so people (myself included) bought them on their mileage earning credit card and just re-deposited the coins into the bank. Some people earned $1M+ miles for free. [http://online.wsj.com/articles/SB126014168569179245](http://online.wsj.com/articles/SB126014168569179245)

<comment><USER19> Do these kind of arbitration opportunities still exist except as mistakes? I assume that channel would have been made unprofitable after discovery...

<comment><USER20> It's arbitrage, not arbitration. I believe the mint began by denying orders from people suspected of being crazy-exploitative, and ultimately terminated the program altogether. (You can still order the coins, but you'll have to pay for shipping.)

</comment></comment></comment><comment><USER21> How the airlines could confront this is by not reliably stopping in the intermediate cities. That is to say, multi-leg flights should sometimes not stop in those some of the intermediate destinations, so that passengers who want to get off there using a cheaper ticket face a gamble: the risk of ending up in the wrong city, wasting time and money to get where they really want. Yes, the plane has to pick up people from those place, but the logistics of that could be worked in with the uncertainty so those people are taken care of. Some other plane grabs them in that case or whatever. Perhaps another airline's plane with some kind of sharing plan.

Say two airlines N and M have flights from A to D. One airline stops over at B, and the other at C. They could enter into a flight sharing agreement so that they pick up each other's passengers at B and C. Then it is not known whether any given N or M flight will stop at B or whether at C. The only sure destination is D.

(Not saying I agree with this, but it's better than other tactics, like bullying customers who are only behaving rationally. "May or may not stop in Dallas": problem solved.)

</comment><comment><USER22> The biggest problem is as they point out - you can't check your bag, and if you board too late they will force you to check it. Then you're screwed. So you get that unique modern form of anxiety - trying to board the plane before everyone else so you don't have to gate check. You better have a bookbag and nothing else.

</comment><comment><USER8> I don't see how this could work for the return flight. If I book Indianapolis to LA to get a cheaper ticket to Denver, I would still need a flight back from Denver, so even if I save 20% on the first flight, I'm only saving 10% on the round trip. Am I missing something?

<comment><USER23> You have to book two one-way tickets. One IND-LAX thru DIA, and another one DIA-LAX. If you booked a round-trip IND-LAX, both thru Denver, and you skipped the DIA-LAX on the outbound, the rest of your ticket will be cancelled.

It can be substantial even doing it one-way, a popular route I flew into ORD was $454 each way on its own, but going thru ORD onto somewhere like MKE was $89-105 consistently. So even with the full-fare ticket back, it would reduce the price from nearly $900 r/t to $600ish. YMMV.

<comment><USER13> Alternatively you could do a second hidden-city trip, eg.DIA->ANX via LAX, and just not not use the second leg of the return trip.

<comment><USER24> airlines will cancel your ticket if you don't get on the plane for the first leg

<comment><USER13> Two one-ways, two different airlines. Fly from, say, LA to Indianapolis via Denver on, say, Delta and get off at Denver. For the return trip, fly Denver to Anchorage via LA on say Alaska Airlines and get off at LA. You have completed your travel plans, and from the perspective of each airline, you just missed your connection on a one-way trip.

</comment></comment></comment></comment></comment><comment><USER25> I heard about this a while back so my friend and I made this search engine: [http://www.flyshortcut.com/](http://www.flyshortcut.com/). Only works in North America, and like most people say - be mindful of the risks!

</comment><comment><USER26> I know it's supposedly new thinking, but I used this trick often in 1970-71. Flying to West Palm Beach from LaGuardia was more expensive than just getting off a flight that stopped at PBI while continuing to Miami.

Thank you Eastern Airlines.

</comment><comment><USER27> This needs a (2011) tag.

<comment><USER28> That's why the tips felt so irrelevant.

Last time I checked booking two tickets made no difference, kayak and all are all well known and I hope that everyone checks at least if there's not a cheaper alternative with these. Usually I can't find anything that I didn't know about, maybe it's because the number of airlines is diminushing every year.

I must also add that I hate those people coming with huge bags, filling the overhead bins as advised in the article. There's no room in the cabin, the old lady won't be able to lift it on her own or you'll get the bag in the face because she's not carefull. In my opinion only backpacks and laptops bags should be allowed, the way it used to be (not so old man rant).</comment></comment>


Ask HN: What do you use to find available domains? - <AUTHOR>

I know gandi.net but that doesn't let me iterate quickly enough, many other sites are dubious, slow or bloated. whois is mostly ok on the terminal but I was wondering if there's a nice web-based solution anybody likes. <comment><USER2> Tip: Never do a domain availability check unless you intend to immediately register the domain.

When you do a domain availability check, squatters get a list of the inquiries, and they may choose to register the domain if you don't.

That's why my blog is at 'realfreemarket.org' instead of 'realfreemarket.com'. When I did an availability check for realfreemarket.com, but didn't register it, a squatter grabbed it.

<comment><AUTHOR> I've always wondered about that myself... that's what I meant by "bogus" :-) Thanks!

</comment></comment><comment><USER3> Try the aftermarket, sites like Sedo and Snapnames. 'Available names', especially .com's, are few and far between now.

</comment><comment><USER4> I like [http://www.leandomainsearch.com/](http://www.leandomainsearch.com/)

<comment><AUTHOR> Not bad but I must say [https://domai.nr/](https://domai.nr/) looks better for my needs, thanks though.

</comment></comment><comment><USER5> I use [https://domai.nr/](https://domai.nr/) it's really brilliant

</comment><comment><USER6> I use domain.nr. It is simple and easy to find new domain names!

<comment><USER7> I do too. Note it's [https://domai.nr/](https://domai.nr/) though.

<comment><AUTHOR> That's really good, thank you!</comment></comment></comment>


Augmented Reality Everywhere - <AUTHOR> http://scrumpy-jack.com/post/5191298339/augmented-reality-everywhere

<comment><AUTHOR> Could AR client apps use QR codes as markers but also fetch animation details from the URL in the QR code?</comment>


Entrepreneurship is not ideation - <AUTHOR> http://bitar.io/the-entrepreneur/

<comment><USER2> I am very impressed with this blog post. Very succinctly put together. Thanks for sharing. For further reading, I highly recommend Steve Blank's (Seasoned Silicon Valley entrepreneur + Prof. of entrepreneurship at Stanford Univ.) "How to Build a Startup" free class at Udacity. Here's a link to class: [https://www.udacity.com/course/ep245](https://www.udacity.com/course/ep245)</comment>


According to Marissa Mayer, long hours and weekend work will lead to success - <AUTHOR> https://m.signalvnoise.com/silicon-valley-arrogance-i-can-tell-you-which-startups-will-succeed-without-even-knowing-what-89aa8ea35d23#.l9nkcyqhc <comment><USER2> The article is overly narrow in its interpretation of her comment - its a figure of speech saying that yes hard work matters. Sometimes execution and its extent matters a lot more than the idea itself. She didn't qualify it by saying nothing else matters. Obviously she knows its one of the factors, but its a way of saying "Yes, hard work is really important for early stage startups."

Not saying she is the best CEO ever, but dumbing down what she said to this level and going on a long rant is just stupid.

</comment><comment><USER3> A VC once told me he would drive by our office at 11pm to see if the lights are on.

"Otherwise you're fucked"

<comment><USER4> Long hours and weekends are cool, as long as I'm getting a slice of the pie! If it's just a salary, nope. If there is equity, there's a good chance I'll toss in regular Saturday afternoons and periodical late nights. No equity? No way.

<comment><USER5> I used to feel the same way, but now I realize that "a slice of the pie" isn't real. If you're a founder and you own a share of the company, then you've got equity. IF you've got options that are vesting (especially during the cliff period) you're really just working for salary as the expected value is zero. (The expectation is you are not working for a unicorn.)

<comment><USER6> The last time I worked for a startup that offered me stick, I said Thanks!, but inside, I was thinking: just pay me a damn salary and let's not pretend this company is my life from here on out.

</comment></comment></comment></comment><comment><USER7> Elon Musk has said the same thing, but he built multi-billion dollar companies instead of tanking them.

<comment><USER8> Will repost an earlier comment of mine:

"I met a director from Tesla just after their unveiling of the Model X. She said a small number of people were assigned to fully assemble / prep each vehicle shown that night.. for roughly two weeks they worked 20 hour shifts and slept 2 hours each night. Most teams were working on them right up until the cars rolled on stage; there was still wet paint on one. Also, it was said a "normal" workweek of 16 hours days isn't uncommon..

She can't wait for options to fully vest and gracefully exit. It's not for lack of thrill, growth, etc. – just that after 3-4 years it is heavily taxing and a pace of sanity is much desired."

<comment><USER9> That's really something i don't understand. After 5 hours of intense work i'm unable to code or think anything. I may be able to do many 4 hours work periods if i'm resting inbetween, but i can't do it multiple days in a row, otherwise i simply start slowing down and take bad decisions.

The best decisions i take are usually in the morning after a good night of sleep, and the problems i've been struggling for the evening simply seem a lot easier.

Even in week-end hackathons, the rookie's mistake is to not get enough sleep in the friday evening, create bugs during saturday, and end up completely unable to work on sunday.

Whenever i coach team, i usually tell them not to run the wrong race. If you're running a marathon, don't run at maximum pace because you'll never make it to the end.

<comment><USER10> Same here.

Management work is different, though. More about making decisions than being hands-on.

</comment></comment></comment></comment><comment><USER11> It all depends on what you are working on. If you are Tesla and building that next big car everyone is so excited to see as a short term strategy it might work.

Working overtime on a sinking ship is rubbish. You need to rush for the nearest exit.

Note: The comment is very very irresponsible on part of Mayer. Yahoo! anyways is not a preferred employer these days. How is she supposed to hire the best talent with these kind of statements ?

</comment><comment><USER12> the only legitimate reason i can think to work long hours is if i am reasonably certain it will translate into a significant, liquid year-end bonus.

if the only reward for meeting an insane project deadline is 'not getting fired', then that's a shit job and it's time to find a better one.</comment>