The Stack Clash - <AUTHOR> https://www.qualys.com/2017/06/19/stack-clash/stack-clash.txt <comment><USER2> This looks pretty brutal.

Quote from Kurt Seifried of RedHat [http://www.openwall.com/lists/oss- security/2017/06/19/2](http://www.openwall.com/lists/oss- security/2017/06/19/2)

" _I just want to publicly thank Qualys for working with the Open Source community so we (Linux and BSD) could all get this fixed properly. There was a lot of work from everyone involved and it all went pretty smoothly._ "

Debian security advisories rapid fire:

glibc [https://lists.debian.org/debian-security- announce/2017/msg00...](https://lists.debian.org/debian-security- announce/2017/msg00146.html)

linux [https://lists.debian.org/debian-security- announce/2017/msg00...](https://lists.debian.org/debian-security- announce/2017/msg00148.html)

exim4 [https://lists.debian.org/debian-security- announce/2017/msg00...](https://lists.debian.org/debian-security- announce/2017/msg00147.html)

libffi [https://lists.debian.org/debian-security- announce/2017/msg00...](https://lists.debian.org/debian-security- announce/2017/msg00149.html)

And just a sample from the Qualys announcement (out of many more), "local-root exploit against Exim", "local-root exploit against Sudo (Debian, Ubuntu, CentOS)", "local-root exploit against /bin/su", "local-root exploit against ld.so and most SUID-root binaries (Debian, Ubuntu, Fedora, CentOS)", "local- root exploit against /usr/bin/rsh (Solaris 11)", as well as proof of concepts for OpenBSD, FreeBSD and so on.

<comment><USER3> Yup, it is, Qualys did some amazing work, and I suspect there are still more problems like this. So if you find stuff like this please let us (Red Hat / etc.) help you help us help everyone (I think that parses correctly =).

</comment></comment><comment><USER4> That is a crazy number of CVEs. At a quick glace I am seeing a lot of local root exploits. Generally speaking if a attacker has an account on your system you are already hosed. But this doesn't bode well for more vulnerabilities of this nature that don't require local root.

<comment><USER5> > Generally speaking if a attacker has an account on your system you are > already hosed.

Isn't that just saying "I don't believe in multiuser systems and/or their security models"...? If so, what specifically do you have against them?

<comment><USER6> > Isn't that just saying "I don't believe in multiuser systems and/or their > security models"...? If so, what specifically do you have against them?

[Core Services] + SSH is generally something you can harden effectively against attacks.

[2903429034902323094230 binaries] is something you generally struggle to maintain security patches/etc on.

The simple fact is, there is just too much attack surface on a vanilla Linux box once you have an account that you can reliably do _EVERYTHING_ you need to do to secure it 24/7/365.

At least imho, given my time constraints/budget.

<comment><USER5> > [2903429034902323094230 binaries] is something you generally struggle to > maintain security patches/etc on.

Does a modern Linux come with that many binaries SETUID?!?

Sorry, I couldn't resist. :P But yea, I see your point. It's a bit sad though; that all these people's hard work (e.g. OP) is all in vain...

<comment><USER7> > that all these people's hard work (e.g. OP) is all in vain...

Part of the reason people's hard work is in vain is because any time the topic of doing things better comes up, a cluster of developers will insist there's no point in improving e.g. filesystem because "once they're on the box, you're screwed." So it becomes a self-fullfilling prophecy.

<comment><USER5> Yea, I get a similar feeling...

In general there seems to be quite diverse opinions out there about "security", and a lot of the space seems occupied by "extreme pragmatics" (or even "anti-intellectuals"). E.g. lots of people feel it's warranted to peddle (simple) falsehoods instead of trying to understand (complex) problems. I can understand it may be the right approach from a day-to-day IT management perspective, but I'm not so sure it's the most viable path towards better security long-term.

<comment><USER6> > I can understand it may be the right approach from a day-to-day IT > management perspective, but I'm not so sure it's the most viable path > towards better security long-term.

Yeah, this is why I had the caveat:

> At least imho, given my time constraints/budget.

The "best" long term path is to have larger security budgets that allow for the objective you and the other folks who dislike my response want. The problem, frankly, is we just aren't there yet.

For instance, our budget for maintaining security is ~5% of the IT budget. A large portion of that goes to perimeter defense appliances (firewalls, barracuda antispam/antivirus filters, etc.) as well as making sure ublock, anti-malware, etc are installed on every machine. The other major chunk ends up in securing WAN-facing services that can be exploited remotely. The last major chunk is user training to get them to stop doing things like pay bills for services we never purchased, clicking on strange links, running strange attachments, etc.

After that, we have no resources to do more than run apt-get update && apt-get upgrade -y for protecting the attack surface once an account is breached. We've got a few things we had to re-compile ourselves manually and break with that process so we moved them out of the package manager for the OS. Our actual applications we build internally also likely have exploitable vulnerabilities if attacked from a local account. Those items never have the budget to be maintained and we certainly wouldn't survive someone taking over a local shell account.

I suspect given this is (roughly) the situation every place I've worked at, its simply too common to be an issue.

</comment></comment></comment></comment></comment></comment></comment><comment><USER8> I'm trying my hardest to understand how this is a novel problem. Maybe somebody can help me?

If I control the stack pointer and can write to where it points, I can write to arbitrary in process memory. Sure!

Is that just valuable as a ROP trick?

But if I have that, isn't just writing to the actual stack more valuable? Why does stack growth matter at all besides being a complication where one can not write to one specific page?

How does this get you to write to out of process memory?

<comment><USER9> Firstly, it's not exactly a novel problem - as the advisory points out, there were earlier public examples of the bug class in 2005 and 2010.

That aside, the issue here is that you can have a program that correctly writes only to properly allocated objects on the heap, and to properly allocated objects on that stack: but if you can get the stack to grow down into the heap without it being detected, now your properly-allocated objects on the heap alias part of the stack (and your properly-allocated objects on the stack alias part of the heap). So now the correct writes done by the program can write to unintended places, like return values on the stack or function pointers in the heap.

The core trick is the _" without it being detected"_ part. What they've done is find places - some of them in library code - that the stack is grown by more than the size of the guard page in one go, and where writing to the guard page itself can be avoided (or in the BSD case, they've found ways that the guard page itself can be disabled). There's also some other clever tricks around expanding the stack and the heap.

</comment></comment><comment><USER10> I'm very surprised. I was sure -fstack-check was on by default. The fact that it isn't secure without it is known for years. Windows compilers have had that check for years. The bug isn't in any executables, gcc and all other compilers should have -fstack-check on by default, with optional disable. I'm even more suprised that people who are supposed to know what they are doing don't compile with it.

</comment><comment><USER11> Could someone explain the situation like if I was 5?

<comment><USER12> On Linux and most Unices (at least on ix86), the heap starts at the bottom of the address space, and the upper bound grows up as you allocate more memory, while the stack starts at the top of the memory space and grows downward as you allocate more stack (stack allocation : mostly function calls and the odd alloca()). malloc() who manages the heap as no idea of where the stack currently ends, and thus can allocate memory at an adress that is also claimed by the stack. When writing to this address, this permit to smash the stack without needing an actual buffer overflow in the attacked code.

There is good news, this looks way harder to attack on 64 bit systems (all the CVE are on 32 bit OS), possibly because the adress space is so huge, and standard OS counter measure like ASLR, stack gap etc all help protecting against the attack.

<comment><USER13> > malloc() who manages the heap as no idea of where the stack currently ends, > and thus can allocate memory at an adress that is also claimed by the stack

The other way around. The kernel has already mapped pages for the stack, and would never hand such pages to malloc unless there's a serious bug in the vm subsystem.

However, code that uses the stack has no idea where the stack ends. And reaching out of the stack is only detected via page faults. If that access happens to land on a mapped page with the right permissions, there is no fault and the code can effectively grow the stack into heap region.

<comment><USER14> Right. The malloc heap has defined starting and ending points. (I say "points" because it's common to use mmap to get a bunch of new pages, which might be discontiguous from the existing heap, but you still know exactly where those pages are.) The stack, on the other hand, is just a pointer.

In theory, you can always decrement the stack pointer for your variables. If you find an unallocated page, the kernel will notice that you're right below the stack and give you more stack pages. There's no other to request more stack memory, the way you can use brk() or mmap() to request more heap memory: you're _supposed_ to page-fault and let the kernel come up with more stack.

In slightly less theory, you can decrement the stack pointer, and if you reach more memory than the kernel is willing to give you, the page fault will turn into an actual segfault, because you'll hit a specially-defined guard page that prevents you from infinitely growing the stack.

In practice, you can decrement the stack pointer by any arbitrary amount and now you just have a pointer somewhere and you have to hope it's either within the stack or in the guard page....

<comment><USER15> Slightly more specifically, if the stack is growing into space that the heap already owns, you don't get a page fault. So the OS assumes that the stack already owns that memory, since there was no page fault. Now if you write to the heap, you can corrupt the stack.

<comment><USER13> > Slightly more specifically, if the stack is growing into space that the heap > already owns, you don't get a page fault.

Exactly. But the stack is only growing in the program's view of the world.

> So the OS assumes that the stack already owns that memory

Nah, the OS is blissfully unaware that the program has moved its stack pointer to point off the stack. If anything, the OS wrongly assumes the program is still operating within the stack space explicitly and rightly reserved for it.

And the program in turn wrongly assumes this memory newly referenced via the stack pointer has been reserved for its stack, because it wasn't killed for accessing it.

> Now if you write to the heap, you can corrupt the stack.

That is right. You will corrupt what the program believes to be stack.

<comment><USER15> From TFA:

The user-space stack of a process is automatically expanded by the kernel:

\- if the stack-pointer (the esp register, on i386) reaches the start of the stack and the unmapped memory pages below (the stack grows down, on i386),

\- then a "page-fault" exception is raised and caught by the kernel,

\- and the page-fault handler transparently expands the user-space stack of the process (it decreases the start address of the stack),

\- or it terminates the process with a SIGSEGV if the stack expansion fails (for example, if the RLIMIT_STACK is reached).

Unfortunately, this stack expansion mechanism is implicit and fragile: it relies on page-fault exceptions, but if another memory region is mapped directly below the stack, then the stack-pointer can move from the stack into the other memory region without raising a page-fault, and:

\- the kernel cannot tell that the process needed more stack memory;

\- the process cannot tell that its stack-pointer moved from the stack into another memory region.

<comment><USER16> This is crazy. I remember thinking when I first heard about stack and heap growing towards each other: uh-oh. But the problem was so blindingly obvious that I just assumed any system written for anything beyond co-operative multitasking had a fix - because if not there was obviously no actual memory safety...

<comment><USER17> What would the fix be? The fact that you can point the stack pointer at arbitrary memory and the CPU will treat that memory as the stack is a feature, and an important one, of the ISA.

The real issue here is that writing programs in memory-unsafe languages is inherently difficult and risky, and fewer programs should be written that way.

<comment><USER16> The design might be fundamentally broken, but if so you're saying that even with an mmu, we can only have co-operative multitasking. That's not the promise of a multi-user/multi-prosess system.

If "all programs are safe", we could just use the Amiga OS kernel and no longer need an mmu, or a similar design.

[ed: apparently windows NT takes steps to avoid this according to a sibling comment. Not clear, but I assume it implies a performance hit for certain heavy stack usage?]

<comment><USER14> I don't entirely follow what you're saying in your first sentence, but I'm going to try to respond to what I think you're saying. If I'm off base please let me know!

1\. Memory-safe languages are about making sure that the programmer's intended behavior matches the actual behavior, that is, eliminating a class of bugs related to memory unsafety. They are a security scheme insofar as these bugs are security bugs, but they're not an _interprocess_ security scheme. In particular, you can write a memory-safe debugger that goes and makes arbitrary modifications to other processes the OS gives it access to. You can even write a memory-safe program in Rust that goes and edits /proc/self/mem. But in these cases, the programmer is _intending_ to mess with process memory directly, so the language isn't obligated to stop the programmer. It is obligated to stop the programmer from, say, overflowing a string and overwriting the return address.

2\. It is certainly possible to design a memory-safe language that is usable for interprocess memory protection. Microsoft had a research OS called Singularity that did exactly this: [https://www.microsoft.com/en- us/research/wp-content/uploads/...](https://www.microsoft.com/en- us/research/wp-content/uploads/2016/02/osr2007_rethinkingsoftwarestack.pdf) But it's another step _on top of_ memory safety.

3\. Preemptive multitasking and protected memory aren't inherently related (although, yes, in the market, most cooperatively multitasked OSes lacked memory protection, and most OSes with memory protections were preemptively multitasked). You can have a preemptively multitasked system with no MMU at all; you just need to respond to timer interrupts and switch tasks.

<comment><USER16> You're right, I leapt over some points, and landed slightly outside the discussion - I guess I think of growing the stack and allocating heap memory as something the kernel should be the arbiter of - and that the api should never allow you to grow into your own (or another process') memory.

I suppose it's fine to say mallloc will return memory, but it's up to the process to check if there are any overlaps - but that sounds a little crazy?

<comment><USER9> That _is_ basically how it works, with the caveat that if you want the kernel to arbitrate your stack expansion you must only expand by a page at a time (and that's what gcc's -fstack-check does).

If you decrement your stack pointer by a large value and then offset it - which is essentially what's happening in these cases - the kernel _can 't_ arbitrate that because if the access lands in otherwise allocated memory it doesn't fault and so the kernel _never sees the access at all_.

<comment><USER16> I meant that the equivalent for mallloc would be that if you allocate 1mb buffer and a 2mb buffer, the kernel might return a 2mb buffer _overlapping_ your earlier 1mb buffer - and be all like: "you asked for 1, you asked for 2 - and you've got 2 - if you wanted 3, you should've asked for 3". Afaik mallloc doesn't work like that - it assumes that you want more memory (and can fail or succeed etc).

I can see how the current stack/heap thing evolved - but I still think it's crazy :-)

<comment><USER9> The stack doesn't work like that either.

All that's happening here is that userspace is moving its stack pointer into the heap it had previously allocated. Note that "moving the stack pointer" is not a kernel-mediated operation.

<comment><USER16> No of course, but the fact that you can "ask for more memory" by growing the stack onto your heap (rather than say, having the two start somewhere together and grow apart) - means that there's an asymmetry: mallloc will give you more ram or fail; growing the stack - can make your allocated memory overlap.

<comment><USER9> Your stack has to grow towards _something_. Sure, you can have it grow towards the bottom of the address space (which, due to wraparound, is also the top - where it will safely collide with the kernel addresses) but that only works for one stack - as soon as you create another thread, its thread has to grow towards something else.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER18> Take note of the Grsecurity section. We already have the technology necessary to mitigate or significantly reduce the impact of these vulnerabilities.

Solid writeup.

</comment><comment><USER19> It's not clear to me why compiling all userland code with -fstack-check would help. Couldn't you work around that by copying or creating an executable in assembly that doesn't write every 4 KB?

<comment><USER20> The issue isn't that a user can run their own code that can stack smash, rather that a user can exploit the smash to run their code in a _privileged context_ (set-guid, i.e. sudo, su, etc.).

</comment></comment><comment><USER2> On 32bit x86, couldn't the SS segment selector be mapped to a completely different set of memory compared to CS/DS/ES and thus remove the possibiliy of the stack and the heap clashing?

<comment><USER21> How would you distinguish between stack pointers and non-stack pointers? Making pointers longer than 32-bit doesn't sound appealing.

<comment><USER2> Good point, I forgot about C allowing passing around pointers to stack variables. Hmm.

<comment><USER2> What if you set up SS to mirror DS, but with a limited range so that any attempt to access memory outside the stack via SS: causes a page fault? Wouldn't any exploit running ESP down into the heap be thwarted by any stack- related instruction (push, pop, or an interrupt?)

<comment><USER22> The accesses causing issues here are not guaranteed to use SS - that only happens for effective addresses [ebp+...] and [esp+...]. If ESP is copied into another register first (which in practice will almost always be the case) then the access will use DS. PUSH will always use SS but that's not the issue here (that only moves ESP by 4 bytes so it'll always hit the guard page). And in modern OSes, interrupts don't use the user mode stack at all - the CPU will switch to kernel mode and use a kernel stack since the user mode stack isn't guaranteed to be valid.

<comment><USER2> Interesting. I was just curious if it would be impossible to write shellcode without triggering an SS:ESP access (via call,push,pop,ret) that would page fault due to protection/selector limits, because that seemed like a neat way to mitigate.

</comment></comment></comment></comment></comment></comment><comment><USER23> A classic always worth reading: [http://insecure.org/stf/smashstack.html](http://insecure.org/stf/smashstack.html)</comment>


Things they don't teach you running a business by yourself - <AUTHOR> https://docs.browserless.io/blog/2018/08/01/running-an-indie-business.html <comment><USER2> A great book on this subject is "Start Small Stay Small" by Rob Walling : [https://sivers.org/book/StartSmallStaySmall](https://sivers.org/book/StartSmallStaySmall)

Rob was running ten simultaneous businesses by himself, (and he has a few kids), diligently managing and tracking his time to run each one as efficiently as possible, and tracking it to make it easy to sell the business to someone some day with a specific intruction manual and estimate of how much time it would take to run that business.

<comment><USER3> Sivers book summaries are the best! Thanks for making them available for the public. I have avoided a few duds by using your list and gone to listen to some great audio books because the notes intrigued me. One of my favorite bookmarks in my browser

</comment></comment><comment><USER4> After ten years of muddling through, I'm finally coming to the conclusion that I was never meant to run a business. By this point, the mere thought that I might give this up and work for a company that would pay me a regular salary and provide health insurance, where I would have colleagues who would support me and take care of all the things I'm no good at... just imagining that scenario brings tears of relief to my eyes.

I'm not a programmer: I work in publishing, promoting Chinese literature in English. I am supposed to split my time between actual translation and editing, and running projects to promote our books and publishing consulting jobs. Project management is horrible; continually worrying about the direction of the company is horrible; four and a half hours of writing emails in the morning is horrible. I am supposed to be spending half my time translating and editing, but it doesn't happen. I am desperate to fuck off with a book and a dictionary into a quiet room and work, but there's an endless number of niggling details to take care of.

If it doesn't give you a high, don't do it. If it takes your high away, DON'T DO IT.

<comment><USER5> I'm desperate to start a business. Over 20 years of working in lead software dev positions and understand the grind that occurs in almost all organizations.

The counter point to your 'horribles', is that the support level you get inside organizations doesn't match the increase expections of a team, and that on larger teams the general level of aptitude approaches average. Occasionally having to work with people who are down right bad at their job. The very effect you espoused of 'company that would...' do all these things for you draws in alot of people who see it the same, and work it like, well, a job (not a calling, or career, or personal investment).

I don't think there is anything wrong with that. A regular wage from a company making money is a good thing, but a strong part of my being believes that I could be successful doing it on my own, and do it to the point of it being art.

Different people at different times in their lives might be more or less suited to one path or another. While i sympathize with the stress you might feel running a business i think there is alot of stress in working for an employer. The people not feeling stress inside companies are people who are coasting. When you're coasting, the part of your being that manifests itself as your work ethic, and professional skill dies a little every day.

<comment><USER4> Thanks for this. I think my current feeling is definitely a bit "grass is greener", and I'm overestimating how much help a larger company structure would provide. But I can't help thinking: running a company requires about nine different skill-sets/areas of expertise, and who has all those? If the job also involves time spent deep-diving into particular work (and literature is even more absorbing than coding), I don't see how one individual could balance the two.

But it's nice to see someone (presumably at a similar stage of life) heading in my direction from the other side. :)

<comment><USER6> girzel,

You have to "cheat". Cheating is when you build your side project/business while employed. Some can arrange this but many simply can't. I chose to quit a lucrative, somewhat stable consulting gig and with reliance on savings to start an independent software provider service in the same field. Boy did I learn about the same skills shortage spoken about in this thread and the article! The emotional rollercoaster point is so true. If you cannot regulate your emotions (basically become a stoic), it will hurt no end.

It's been 5 years since I started and I have only managed one enterprise sale (that sale itself took me two years to sign). Been hobbling along in zero growth purgatory since. If this client cancels I am fucked.

It is easier to imagine a life of zero responsibility and drastically reduced stress and anxiety. It's a fantasy for me now imagining myself "cruising" (another poster's word) at a full time job. I am 45 now and jokingly imagine myself unemployable. I wouldn't last a day being microanaged.

My autonomy is important to me. My autonomy gives me full control over how I develop my craft on my own schedule.

When asked by people how things are going, it's always "fine! Great! All good!" (But the ruse is only as thin or thick as my skin)!

<comment><USER7> > I am 45 now and jokingly imagine myself unemployable.

You are not, far from it. Running your own business has taught you many lessons which will come _very_ handy when looking for a job. At least that's my experience.

<comment><USER8> > Running your own business has taught you many lessons which will come very > handy when looking for a job.

I imagine it's very dependent on what you do, what your skills are, and what type of industry you're in (and, finally, who is interviewing you). I've done my own software dev/consulting for a decade now and am possibly unemployable (or, at least, for most positions). "Standard" dev jobs - I've interviewed for some, and may be intimidating to some (and yeah, I realize this may be a full- of-shit self-aggrandizement view of myself too). For a decade, when coming in to a project, I'm typically given a wide range of access to multiple people, and a wide variety of information, to help make the best decisions possible. I've interviewed for "development jobs", and the environments are typically the opposite - info lockdown, do the assigned tasks, etc.

I've been in those situations, and watched as companies go under because of bad decisions, and can't easily deal with not having more info access to understand the decisions/directions (even if I don't agree with them, seeing the bigger picture can help me accept, or... start to look elsewhere).

So... yeah, the GP (and myself) may not be completely unemployable, but the sorts of 'jobs' where someone wants the sort of experience someone has running their own business... they aren't as plentiful, and often don't get advertised (and likely aren't going to be the sort of thing body-shop recruiters are going to be reaching out to you about). (and age is no doubt a factor as well - I'm north of 40 and think 'employability' is thinner than it was for me 15 years ago).

<comment><USER7> I agree that being employed as a regular developer gets harder and harder with age and with experience outside of dev world, but at the same time you are getting better and better at positions which require more business skills, like team lead (if your tech skills are still good enough) / product manager / CTO / tech cofounder / ... There are many companies that don't know they need this kind of person, and it might be difficult to find a match. But once you're in, you can make a huge difference with this skill set.

<comment><USER8> > There are many companies that don't know they need this kind of person, and > it might be difficult to find a match.

that sounds like a different angle of saying what I was saying. if a company doesn't know they have a need for what my skills are, i'm less likely to employed by them. if the majority of companies in an area also don't know they have a need for my skills, i'm less employable (or perhaps unemployable) in a particular area.

i've gotten way too good at seeing roadblocks well before other people do, and the roadblocks are almost always nontechnical. This can be taken as 'having a negative attitude', but it's just pragmatism born out of experience (yes, understood, my delivery/tone may play a part in this, but sometimes I'm just the guy saying something that someone above me doesn't want to hear). As an external consultant, you're brought in to be able to say those hard things that people perhaps can't say for themselves. As an employee... you're potentially "toxic".

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER9> Maybe it's because I'm a rural Michigander, or maybe it's because I'm 35. Whatever the case may be, whenever I read a line such as, "It goes by many names: boot-strapped, solo-founded, self-funded, indie-hackers...etc... and it's pretty hot right now!" I have a visceral reaction. Around here that's just owning a business. No one cares about how it's structured or how it's funded. Trying to quantify your business to others in such ways is so much window dressing.

That being said, the rest of the article was a nice read.

<comment><AUTHOR> Definitely. Even the term "startup" is overloaded. Simpler terminology, like you mentioned, would go a long way to make newcomers feel more welcome.

Thanks for the kind words!

</comment></comment><comment><USER10> Being an exec in someone else's business and running my own show, the hardest things have been the most basic: 1) Managing people. 2) Collecting from clients. 3) Finding and cultivating clients for the long run.

It's that simple. What's interesting is, I don't recall ever touching on those issues with any depth in my undergrad business classes. Sure we studied "best practices" in hiring, managing, layoffs, etc, but that's very different than the day-to-day of building a team from scratch and getting people to produce at their best level. Likewise, I took a lot of financial management and accounting classes, but that's totally different from some jerk customer who decides they just don't want to pay their bill out of spite, forcing you to litigate, where the dollar amount represents potentially months of payroll. There are so many things like this that are _basic business_ and yet until you've been there, it's hard to really know how to prepare for it or build the skills for it.

<comment><USER11> I agree.

I never did an MBA, but have talked with a lot of people who did. Collections, financing (not the high falutin' corporate finance they teach, or corporate accounting, but small business finance: small business loan mechanics, covenants, banks versus ABLs versus factoring vs equipment leases), basic labor regs, how to sell, how not to underprice, how to discover customers' "real problems", how to manage performance, how to deal with an otherwise good employee going through personal problems, how to write a good job posting that doesn't read like it was written by an HR drone, etc are all things that don't seem to be commonly covered subjects.

The only solution seems to be to go do all those things and make the mistakes, but I think much of it could be accelerated through good training.

</comment></comment><comment><USER12> Another great learning opportunity is to look at the millions of other small businesses around you.

The coffee shop you're sitting in to write code... the proprietor has:

      * Payroll expenses
      * Marketing, Sales, Promotion
      * Rent
      * Recruiting
      * Supply chain
      * Inventory and storage
      * Utility bills
      * Legal entity structure
      * Accounting / taxes

Fundamentally, all small businesses have the same core challenges. Indie software shops are not much different.

<comment><USER13> How many of these could be outsourced to trusted third parties?

<comment><USER14> None. I exaggerate a bit. I don't mean to be negative, but you always need to monitor, check, manage. Employees or third parties. In my experience, you never "outsource your worries", you just manage them better. Third parties execute what you want them to execute.

</comment></comment></comment><comment><USER15> One thing I learned that after a while it gets super easy to convince yourself that just 15 minutes of playing outdated online FPS games is OK, then 2 hours later you're still playing, and nobody is there to say "What the hell?". Is this normal?

<comment><USER16> If you want to play when you feel like playing and work when you feel like working you need to be ok with working at 8pm on a Saturday. Otherwise you won't get anything done.

Also, exercise more. I swear I get more time out of exercise for my business than I put in.

<comment><USER17> Exactly - you have to hold yourself accountable for working hours, or hold yourself accountable for getting the work done.

Agree on the exercise as well - no matter what time I go to the gym, my "best" working part of the day seems to come afterwards.

</comment></comment></comment><comment><USER18> The rollercoaster is real and I somehow haven't expected it even after diligently reading HN for years. I'm afraid that if I have to go back to normal work it won't feel like life anymore and will be terribly boring

<comment><USER10> Spot on. The seasonality and ups /downs of even well-established small businesses is exhausting. I've met way too many execs / owners of $10-2MM businesses where 99.9% of that is riding on 1 or 2 clients. Scary.

</comment></comment><comment><USER19> Every one of those things are exactly what they teach you in every one of these articles, isn't it?

What they don't teach you is how to register a company, how to obtain trademarks or patents, how to do your taxes, what to deduct. How to follow laws you probably haven't ever heard of. How to hire your first workers, or how to manage them. How to hire your first manager. How to do budgets, how to do pay checks, well how to do finances in general.

I mean, it's a good article, it's just exactly the same as all the others.

<comment><USER20> I have, on occasion, contributed to the pile of "these articles" that you speak of, and I might suggest that the reason your things get skipped is that they're not particularly relevant. But just in case:

1.) Register the company: (optional) 1 hour finding and filling the "Sole Proprietor" form for your state. Or just don't bother.

2.) Trademarks and Patents: Completely unneccessary. 15 years in, I have none of these for any of my businesses.

3.) Taxes: Turbotax, click through whatever "business" one they guide you through and deduct what it says to deduct.

4.) Mystery Foreign Laws: Ignore them completely. If the European Cookie Popup Enforcement Division ever knocks on your door, follow their instructions. Until then, sweat things that actually matter for your business.

5-10.) Employee Stuff: Don't hire employees. As a one man shop, you'll find you can pull most stuff off yourself. Again, 15 years in, I've probably only paid 2 or 3 freelancers for short gigs outside my area of expertise. Their fees go in the appropriate box on Turbotax above, and never hit the threshold to need 1099s or anything silly like that.

So I think the important takeaway is that most people tend to worry way too much about all the little administrative details. And it's a shame, because all that can do is scare you off.

If you ignore all that stuff, and assume it doesn't apply to you, chances are it never will. Or at least by the time it ever _does_ , you'll already be up and running, with money in the bank you can use to address it.

Best of luck!

</comment></comment><comment><USER21> I'd like to add:

-Learn how taxes work or get an accountant

-You won't be able to afford health insurance for your family (in the US)

<comment><USER22> But why?

Family plan on coveredca site costs about $13k/year. Or even less if your business is not yet profitable enough.

</comment></comment><comment><USER23> I read an interesting comment either here or on IH the other day about the difference in emotional investment when you're running your own business vs working for someone else.

It was something along the lines of "why is it so easy to take feedback on your work from a boss, but when the same feedback comes from a customer it is so much more personal. at work its a lot easier to ship something that's good enough, but for some reason everything has to be perfect when you're working for yourself"

I totally butchered the quote, and wish i could attribute it properly, but i thought it was a valuable perspective

</comment><comment><USER24> One of the biggest issues when running a bootstrapped company is retaining focus. There are so many cool features that can be added, but so little resources to implement them. Spending time on something that is not really needed pushes the point of profitability further and further. Basically, the goal is not to make a product that "doesn't suck" because it's not possible. The goal is to find the most optimal way to make it suck less.

This is true for funded startups as well, but a bootstrapped business has a way smaller error margin for wrong product management.

</comment><comment><USER25> Great summary of of the challenges involved!

Small bit of feedback on your site: I run a business, and am not a programmer. I use a programmer. I can't tell if this is something would use, or not.

You probably don't want to optimize around this use case, but I was looking for a single line that might say "business owner who employe a programmer? Click here to see if this would be useful for you" \--> leads to a description of how browserless helps my programmer

<comment><USER7> Unless you know it would help you (as a manager), I would advise you let the programmer pick his own tools. You can still check with other programmers if his choices make sense, but be careful if acting on this information. Just make sure he uses some sort of CVS (Git is most common nowadays), other than that... any competent programmer should know about these things, and it is more likely that he finds out about them from their peers.

<comment><USER25> Well, that's the thing, I don't know enough about the service to know if it is:

* Something useful for my _organization_ even if my programmer leaves, or

* something useful for a programmer personally

Me and my programmer do talk about stuff to be used by my organization. Which is mainly just him in tech terms, but i want everything documented to mitigate bus factor. So we talk generally about tools. Also if it's a paid thing, that's he's using for working on my stuff, then I would pay for it.

</comment></comment></comment><comment><USER26> I started a company in south america (American here), and navigating the legal system has been the most life sucking thing ever. The idea was simple enough, but the execution from a legal perspective was something I was completely unprepared for. Also did this completely alone...That being said, the hard part is done ;)

<comment><AUTHOR> It took me at least several weeks to get an idea of what the legal landscape even looks like, and what/whom I needed to engage. Definitely could be easier, and in its own way it is a gate-keeping mechanism I feel.

</comment></comment><comment><USER27> For me, it's not that they didn't teach me, it's just that there are so many lessons you have to learn yourself through experience. It's hard to teach how to select, train and keep good employees, how to recognize toxic ones early and fire them, and how to deal with employees who are not bad but not great. It's hard to learn how to pace yourself while also growing the business. You can be taught communication skills but it's like learning a instrument, you need deliberate practice to succeed.

</comment><comment><AUTHOR> Just wanted to chime in and say thanks for the discussion here. One of my favorite parts of Hacker News is reading through comments and challenging beliefs I've held, and absorbing new ones. Lots for me to think about, and hopefully the community as well. Cheers!

</comment><comment><USER28> Yo Joel, super rad to see you here. I'll check out browserless

<comment><AUTHOR> Cobin! Wish you were still around PDX, really miss hanging out :) Let me know when you're back and we'll get 808 again!

<comment><USER28> Good times, miss you, man

</comment></comment></comment><comment><USER29> Thanks for this, as a founder myself I completley agree with the 'Be a customer of your product' point. Spot on!

</comment><comment><USER30> We needed to know more reasons on why not to open a business. Tell us more about how hard it is. !(It helps)

<comment><AUTHOR> :) This is something I've been thinking about as well. I'll have to write up something more details and "when not to" as it's just as hard to pin down as "when you should." Thanks for chiming in!

</comment></comment><comment><USER31> Yeah... pretty much right.... !!!!!

</comment><comment><USER31> Thanks

</comment><comment><USER32> If by they you mean bloggers, I think you are mistaken.</comment>


The guy who made it so difficult to open your bag of potato chips  - <AUTHOR> http://www.rheothing.com/2012/05/im-that-guy.html <comment><USER2> The guy we really need to find and punish is the one who invented "rigid plastic clamshells".

The kind that "conveniently" transforms from product packaging into a razor- sharp weapon while you are trying to open it.

<comment><USER3> Clamshell packaging was made for retail shelves. To prevent shrinkage and increase product visibility, it was designed to be transparent while simultaneously difficult to open.

The explosion of Amazon and other online retailers made the advantages of clamshell packaging moot. However if you are a manufacturer, it may not be economically feasible to produce two different types of packaging for different retailers so lowest common denominator wins out.

Amazon has tried to combat clamshell packaging[1] with a few manufacturers (Fisher-Price, Mattel, Microsoft), but it has yet to be adopted by the rest of the manufacturing industry.

[1]: [http://bits.blogs.nytimes.com/2008/11/03/amazoncom-cuts- pack...](http://bits.blogs.nytimes.com/2008/11/03/amazoncom-cuts-packaging-to- combat-wrap-rage/)

<comment><USER4> > To prevent shrinkage and increase product visibility,

Which is also a feature to discourage shoplifting.

<comment><USER5> Out of curiosity, what did you think 'shrinkage' meant in that context?

<comment><USER4> Wow yeah I was really confused. English is my third language and I can often figure words that I don't know from the context except that in this case I interpreted 'shrinkage' as some kind of a tendency do produce smaller products (electronics get smaller for instance). And I thought ok it seems a large package makes the product more visible on the shelves. Then I thought "ok" actually a large package would be hard to sneak under one's shirt. So it would be good for that as well.

<comment><USER6> "English is my third language"

I don't think that's the problem - I had no idea what shrinkage is and:

\- English is my first language

\- I've worked in retail (though I rarely paid attention back then)

</comment></comment></comment></comment></comment></comment><comment><USER7> I love learning about things I would never come across in everyday life, like how a packing machine works and the problems no one would ever think to think of like air pressure and altitudes. Then also the restrictions put in place and how to come up with a creative solution to a problem. This is the kind of stuff I live for.

<comment><USER8> The air pressure certainly has an effect. I live in an only somewhat-high- altitude city (Calgary) and most of the chip bags you see are puffed up like balloons.

<comment><USER9> Once had a bag of chips burst while driving up into the Rockies.

</comment></comment></comment><comment><USER10> I think the most interesting part of this post was the comment about how they use multiple scales with chips to get closest to the desired value.

This is really a neat hack that probably allows for much less precise chip dumpers. I'm reminded of how awesome randomized algorithms in CS can seem, but in real life it is just extra magical.

<comment> excuse-me More a case of discrete chip mass.

You could have very accurate chip scales, load cells are cheap and very accurate - but how do you select exact 'N' grams of random sized potato chips?

Having a set of pans, where the first has eg. 17chips with a mass of 4.5g, the next has 19chips with a mass of 5.9g etc and then selecting from 4 of them them to hit the 20g bag size is very clever.

<comment><USER11> Exactly. It allows for less-precise (i.e. more variability) _chip size_ , not chip scales. :)

Simplifying the scenario might clarify what's happening. Imagine any given chip could weigh 1-2oz. And you are trying to fill a 2oz (minimum guaranteed content) bag. You already have 1 chip in the bag, weighing 1oz. The next chip you add (think "marginal" from econ class) weighs anywhere from 1-2oz and could tip the scale all the way up to 3oz, when you are only looking for 2oz in the bag. But if you use two scales, you have now a choice of TWO chips to put in the bag, so you pick the one that weighs closest to 1oz. And ultimately this allows you to fill more 2oz bags with the same quantity of chips.

</comment></comment></comment><comment><USER12> At 4:10 in this video <https://www.youtube.com/watch?v=LkqBbr7Ewsw> you can see a VFFS machine in action.

(I find 'how its made' to be musak for nerds but that is a different post :-)

<comment><USER13> You can link directly to 4:10 in the video.

[https://www.youtube.com/watch?v=LkqBbr7Ewsw&t=4m10s](https://www.youtube.com/watch?v=LkqBbr7Ewsw&t=4m10s)

<comment><USER14> Holy shit that's brilliant.

I admittedly haven't been to Youtube in forever, but that actually got me to click, if only to find out how (other than altering the querystring by hand) you did it.

I still didn't see how to do it though. Is that a logged-in option perhaps or am I just missing something?

<comment> X-Istence When you are at the time you want, right click on the video, and copy the link with the time.

"Copy video URL at current time"

That's all there is too it :-)

<comment><USER15> Or add &t=XmYs to the URL (where X is minutes and Y is seconds).

<comment> X-Istence > "(other than altering the querystring by hand"

Parent I was replying to already knew that part...

</comment></comment></comment></comment></comment></comment><comment><USER16> I find this article to be quite frustrating. It's like reading about how some process was too slow, so they looked at the variables which include a faster processor, more RAM, and larger storage. Ultimately, they chose more RAM and developed a new algorithm and all was solved. But then they never tell you what the algorithm is. Or why it allowed them to keep within the constraints of the same processor and storage.

In this case, it's a new adhesive. But how was that developed? What makes the new adhesive better suited to high-pressure applications while keeping the temperature and time constant? Inquiring geeks want to know!

</comment><comment><USER11> OK now let's find the guy that invented those crinkly Sun Chips bags.

<comment><USER17> agreed - and then lets ask them about the total fabrication that they are biodegradable.

<comment><USER18> Biodegradable... eventually.

edit: So I looked it up and it should only take 14 weeks in an active compost pile. I wonder if anyone has ever tested it?

<comment><USER19> Almost no change after 25 weeks in a home compost pile: <http://cockeyed.com/science/compost_chips/sunchips.php>

<comment><USER18> Interesting. I'm skeptical of the marketing because 14 weeks doesn't seem like long enough. I'm also skeptical of this experiment though.

Sunchips specifies 14 weeks in a hot and active compost. A new compost pile (like in the experiment) would not be very active compared to an old one, especially since he didn't add any worms to it but he did get the water and turning right. He also mentions that it was cold and rainy in the weeks after he started his compost. An old compost would shrug this off but it would have a negative effect on a newly started compost.

<comment><USER20> A friend of mine teaches gardening to children and they tried it. After 4 months the bag was a bit thinner and worn but not drastically different. They figured that in a large communal compost it might only take 14 weeks to biodegrade as communal composts are considerably hotter then anything you could have at home.

</comment></comment></comment></comment></comment></comment><comment><USER21> Seems like a good design would be to have seals that are extra-weak to shear forces while being strong for all the other kinds.

<comment><USER22> One type of seal I see has a nick in the side.

It's still sealed, but the nick gives you something to leverage, so you can tear the packet open. Perhaps this isn't as common in the US?

<comment><USER23> The nick you're describing creates what structural engineers call a 'stress riser' in the material of the bag. It focuses the force you exert on the bag to a small point, from which the tear will originate.

Stress risers are a common cause of structural failure, and are usually designed around. Some well known examples where they cause failures: rectangular window openings in aluminum fuselages, knots in fishing line, a poorly designed head tube lug on a steel bicycle frame.

In this case, however, the failure of the material results in a good outcome: snack time.

</comment></comment></comment><comment><USER24> When i started skiing, I used to have bags of chips explode on me while driving from the California coast to Lake Tahoe, scared the crap out of me. I just decided to buy vacuum packed stuff up there.

</comment><comment><USER25> _"The point here is that while technical options exist to prevent premature opening of the bag, such as reducing the initial air pressure in the bag, attempting to add this to the existing processing equipment would be a nightmare. So it was necessary to increase the seal strength."_

You could also reduce the air pressure _in the factory_ , e.g. by building it in one of the aforementioned high-altitude regions.

<comment><USER26> And/or heat up the air filling the bag. As air cools, the volume decreases.

The right solution would be to squeeze to depress the bag a bit as it's sealed. Increasing the seal strength is a quick and dirty hack, but as we've all learned too well from software, the right solutions often got trumped by quick and dirty hacks. The customers just have to live with the consequence.

<comment><USER27> Your ideas have other suboptimal consequences though - sucked-in bags don't look as nice on the shelf, and in fact they look _smaller_. This makes them less attractive and thus less likely to be purchased.

</comment></comment></comment><comment><USER17> I'm usually pretty disappointed, because on a failed opening attempt I end up crushing those chips, and then feel like I didn't really get my money's worth.

<comment><USER28> It's alright. Chips and cereal are sold by weight, not volume. Some settling (or crushing) of contents may have occurred during shipping and extraction.

<comment><USER17> I realize they are sold by weight, but I'll be honest, the full size merchandise is worth more to me. It is even worse on cereal, my wife saves the end of the box for me because i'll eat it. I prefer the full size, but throwing out the 'fluff' (crushed bits and powder at the end) seems like a waste.

</comment></comment></comment><comment><USER29> Now I know who Kettle Chips hired to make their impossible to open bags.

<comment><USER30> I was just thinking about how Kettle Chips have a small but pronounced notch that you can grab and pull. I haven't had any angst opening a bag of chips in a long time.

<comment><USER31> And here i was, cursing the idiot at kettle who thought eating chips from the side of the bag was a good idea. Opening from the top allows for easy reach and easy reseal.

<comment><USER30> _eating chips from the side of the bag_

After you easily open the bag of chips, you pour them into a bowl and set on the table. Do you drink wine straight from the bottle or pour it into wine glasses?

<comment><USER16> My good fellow, I'm sure that when you partake in the delicious fruit known as an apple, undoubtedly you do like I and first neatly slice and core the apple. Once the fruit is thus prepared, I find that arranging it neatly in a circular pattern on a fine porcelain plate (preferably covered with an exquisite paper doily) is a most acceptable presentation format. How uncouth are the heathens who consume the apple straight from the stem, exposing the unsightly core in plain view.

</comment></comment></comment></comment></comment><comment><USER32> Not so difficult if you keep one pinkie nail 3 inches long and razor-sharp (as do I).

</comment><comment><USER33> _so when trucks would drive their chips out to California, some of the seals would open up due to the pressure difference between the high altitude air and the air sealed inside the bag_

This is backwards, isn't it? Less dense air from Colorado would shrink the bag in California.

<comment><USER34> Yeah, it is. Your shampoo usually opens on the pass.

At a guess, maybe he meant the plants were east of the mountains, not west, so they would have to drive over them?

<comment><USER33> Oh, right, the mountains :)

</comment></comment></comment><comment><USER35> > Other options besides a stronger seal are technically possible, but not > economically feasible.

It would have cost next to nothing to attach slabs of foam rubber or gentle spring plates to the sealer. As the two sides move together, the air is gently squeezed out of the bag first. Sheer incompetence.

<comment><USER36> Wouldn't evacuating the air from the packaging make the chips inside the container crush and break easier?

It's always been my understanding that the head room inside the package helps protect the contents.</comment></comment>


Climate Solutions: Is It Feasible to Remove Enough CO2 from the Air? - <AUTHOR> https://e360.yale.edu/features/negative-emissions-is-it-feasible-to-remove-co2-from-the-air <comment><USER3> Removing CO2 might be necessary to stop global warming.

But what chance does this sort of ambitious effort have when more and more states don't even want to deal with the ordinary problem of reducing CO2 output?

It seems to me that anyone caring about climate change needs to have a generally pro-science position politically.

<comment><USER4> > Removing CO2 might be necessary to stop global warming.

> But what chance does this sort of ambitious effort have when more and more > states don't even want to deal with the ordinary problem of reducing CO2 > output?

There are cheaper geo-engineering methods that don't attempt to directly reverse the problem, just (locally) mitigate some of the consequences, that could be done unilaterally by a state. E.g. stratospheric aerosol injection (less glamorous but a much cheaper than parking sunlight-filtering-satellites between the earth and the sun).

> Unlike the control of greenhouse gas emissions, which must be undertaken by > all major emitting nations to be effective and is likely to be costly, > geoengineering could be undertaken quickly and unilaterally by a single > party, at relatively low cost. Unilateral geoengineering, however, is highly > likely to impose costs on other countries and run risks with the entire > planet's climate system.

[https://www.cfr.org/content/thinktank/GeoEng_Jan2709.pdf](https://www.cfr.org/content/thinktank/GeoEng_Jan2709.pdf)

<comment><USER5> Did you read the article? The person interview specifically mentions aerosol injections and possible unforeseen consequences of bio-engineering. It seems rather stupid to duct tape your leaking ship knowing that you'll arrive at the port soon.

<comment><USER4> i didn't read the article, but i did attend a couple of lectures last year about geoengineering proposals.

i agree that e.g. aerosol injection proposals seem rather stupid, won't actually fix the problem, but may just mitigate some of the many consequences of the problem, and also cause entirely new problems.

on the other hand, i suspect it is much more likely that geoengineering proposals will actually happen in preference to hypothetical negative emission technology, as geoengineering doesn't need a group of countries to agree on doing it, and (some of them) are relatively cheap and easy to do using existing technology.

</comment></comment></comment></comment><comment><USER6> I wouldn't mind living in this future. I'm haunted by a beautiful idea:

Imagine standing outside in sunlight. Above the clouds in the course of the sun is a faint band a bit wider than the sun. Specks, motes. Thousands of them. Across the band some glitter, some are dark - like dark specks. Those covering the sun are almost all dark. If you carefully look at them through a filter that let's you see the sun's disk, you can make out a fuzzy outline not too unlighy the continents, with a few extra spots in between. Earth has a ring. An artifical one, much wider than the ones Saturn has - more like a ribbon, actually. The motes are each large flat reflective surfaces. Flat disks made of reflective plastic films. Microns thick with as much area as is practical to make launch and unfold at scale. They orient themselves using current flowing around their rim using electricity generated from solar power on their main body. The current in the rims orient them relative to earth's magnetic field. They also act like solar sails when needed, using solar wind for minor maneuvering and they use small micro ion drives for positioning. Each is a pixel. It can reflect sunlight completely away from the surface of the earth. Or to a targeted spot on it. They can match their rotation to their orbit and cast a variable shadow: from a slim wisp to their full area. All in all. All of them together can dim the sunlight falling on the earth by up to 2%, but with precise control per region. Many targeted on the same spot can boil (or slowly evaporate) large bodies of water or heat large volumes of air within specific control. They can be weapons. Terrible ones: melting metal and rock for small focused regions. But mostly they are tools - gardening tools. Weather, and more importantly climate is something that they are used to steer. After wrecking the sort of balance we found when we started here we were responsible for establishing a new balance.

Most of their work is reducing the incident solar radiation falling on the earth's surface. They dim the radiant energy on the surface in line with the current climate control program. For the continents they mostly just reduce incoming energy. Over the ocean some areas are dimmed less to help cloud formation. This extends their influence immensely as we then increase the earth's albedo using the extra cloud cover, reflecting a lot more light than ocean does. They fiercely shield whatever glaciers we could save. The ones on the night side are used for controlled lighting in a few cases. The baby drone-planted forests are sometimes given extra sunlight. And a few cities are given the occasional extra light when safe. The ones not positioned for blocking sunlight focus light and heat to manage weather systems. Parts of the garden's weather systems can be managed. On the one side of a continent clouds are formed by heating the ocean. These clouds are shielded and shepherded through shielded corridors and allowed to condense and rain in the interior. In places large inland water bodies were made. In other places river like canals were melted through rock. The natural forests and areas we could save are given special status:Bonsai, and we try to keep them vaguely in line with what they originally were, at great cost. But much desert is farmable and a lot of previously rough terrain is being manicured. Some spots of the garden are never tame and recalcitrantly fights back. There is a degree of success in using them to manage ocean currents, but it's difficult and doesn't always work. They don't have the strength and finesse required to do that at scale. We need other tools for that. Wind currents are easier. They follow simple temperature gradients and with trial and error and a lot of computer modeling these are mostly directly managed. Weather is at a coarse (and often fine) level controllable within the constraints set by climate regulation control. A new stable balance against the current level of atmospheric composition can be maintained - within reasonable constraints. We still need to spend decades or centuries cleaning up our carbon dioxide mess. New forests, huge atmosphere altering factories and sublimation pits help, but it is a long term project.

<comment><USER5> Gee, I wonder what could go wrong with this vision.

<comment><USER6> Lol! ;-) Um... Exactly! I don't think real world problems are solved, we just exchange them for different ones. You hope to go from: "there is no software for my platform" to "there is so much software for my platform it is hard to find a perfect fit" or "I'm so poor I can't afford to eat" to "I struggle to find an investment banker that I like to handle my investments".

Our current situation is sort of a consequence of:

Imagine a world where beasts of burden don't toil under the hot sun - <USER2> machines powered by refined oil products allow for the cultivation of crops, feeding millions. Where machines relieve people of brutish work, freeing them for more satisfying and valuable pursuits. Where durable and strong materials can be made cheaply from petroleum-based products that millions of households can enjoy. Where hundreds of millions of people can be fed using more efficient agriculture that uses chemically produced fertilizer....

And so on and so forth...

</comment></comment></comment><comment><USER7> Shouldn't we be removing it from the oceans since they've been absorbing the excess according to some old articles on HN?

<comment><USER8> The largest and, long-term, most effective carbon sink are phytoplankton. They are responsible for half of all photosynthesis, thus absorbing tremendous quantities of CO2. As they individually die, they over millions of years accumulate thick carbon-filled layers at the bottom of oceans. _This_ is the ultimate origin of oil deposits, by the way.

</comment></comment><comment><USER4> I'm reading "The Ends of the World: Supervolcanoes, Lethal Oceans, and the Search for Past Apocalypses" by Peter Brannen. Most of the book focuses on past mass extinction events, but there's a bit of discussion and comparison to what's going on in the world now. It's written in a fairly popular-science-y style, but there's lots of references to further reading. Some quotes:

> [...] humanity has not yet come anywhere even remotely close to the death > tolls of the major mass extinctions of the past half-billion years ... yet. > In the past 400 years, there have been documented extinctions of some 800 > species. This is a tragedy, to be sure, and likely a massive undercount, but > when divided by the 1.9 million species known, 800 extinct species amounts > to an extinction of less than one-tenth of 1 percent - a far cry from the > End-Permian, during which, generously rounding up, almost 100 percent of > complex life on earth was killed.

re: the End-Permian mass extinction

> "Five hundred million years is a really, really, _really_ long time. And > [the End-Permian mass extinction] is the single worst event in the last 500 > million years of earth history. So your scenario should not be sort of a > bad-day scenario. [...] It's closer to a one-in-a-billion event."

> [...] End-Permian sites across the planet from the ancient ocean [...] > similarly recorded a carbon cycle jackknifing. Where did all this extra > light carbon in the atmosphere come from? One way is to kill all the plants, > plankton, and animals in the world. [...] But the carbon isotope swing at > the End-Permian mass extinction is so severe that many other scientists > think that the collapse of the biosphere isn't enough to explain it.

> [...] At the end of the Permian, Siberia briefly turned inside out as the > Traps covered Russia in more than 2 million square miles of lava.

> [...] "Basically the entire global economy rests on how quickly we can get > carbon out of the ground and put it in the atmosphere", Ridgwell told me. > "That's basically the global enterprise. And there's a lot of people doing > it. Geologically, it's a really impressive effort."

> But as exceptional as humans are, estimates of the carbon released in the > End-Permian mass extinction range from an utterly catastrophic 10,000 > gigatons of carbon -- twice as much as we could ever burn -- up to a mind- > meltingly unfathomable 48,000 gigatons.

> [...] "So taking the modern ocean and adding 40,000 gigatons of carbon -- > like in the End-Permian -- it would take you from, say, 300 ppm to 30,000 > ppm CO_2," Payne said. We both started laughing. This number is > incomprehensible.

> [...] For now, typical estimates place End-Permian atmospheric carbon > dioxide somewhere around 8,000 parts per million [...]

> [...] In the long term the oceans can keep up with a huge buildup of carbon > dioxide in the atmosphere, as long as it happens slowly enough. The gradual > process of weathering breaks down rocks on land, washing them into the ocean > and, in doing so, buffer the seas against acidification [...]"

> "Well, the rate at which we're injecting CO_2 into the atmosphere today, > according to our best estimates, is ten times faster than it was during the > End-Permian. And rates matter. So today we're creating a very difficult > environment for life to adapt, and we're imposing that change maybe ten > times faster than the worst events in Earth's history".

For reference, the human endeavour is injecting roughly 40 gigatons of CO_2 into the atmosphere every year.

<comment><USER9> > "Well, the rate at which we're injecting CO_2 into the atmosphere today, > according to our best estimates, is ten times faster than it was during the > End-Permian. And rates matter. So today we're creating a very difficult > environment for life to adapt, and we're imposing that change maybe ten > times faster than the worst events in Earth's history".

Geologist here! That's a good quote. On geologic timescales, a million years is short! Accordingly, a lot of our effects on the environment are scary more because of their rate than their absolute magnitude (so far). I think humanity as a species has been doing a pretty good job of implementing that old facebook motto "move fast and break things". We'll see how that works out for us.

</comment></comment><comment><USER10> There is this amazing organism that removes CO_2 from the air for free.

<comment><USER11> And then release it back when it dies, biomass sequestering doesn't work well unless you can find something that would not decompose and then you need to figure out what to do with it.

<comment><USER10> How do they release it back? A process that takes a few hours (burning) or a process that takes years? How did the hydrocarbons get in the ground in the first place?

You can't be serious with "something that would not decompose". Entropy literally disfavors it. The point is to tamper the rate, not to completely turn all C into diamond and jettison it into the sun.

</comment></comment></comment><comment><USER12> Jesus Christ hacker news, get your shit together. Way to many Climate Change denialists/minimizers here to be anything but appalling, considering the reputation of the site's user base.

Scientists agree: Climate change is terrifying, climate change is human caused, and climate change is here now today, threatening to be the effective end of our species in a number of decades you can count on your hands. On top of which, it only takes mildly pessimistic scenarios to reach time spans you will probably live to see.

</comment><comment><USER13> God help us when the fraction of gases in the atmosphere can be set by the political process. How often do we get a ruling class that you would trust with that decision? And if we can't trust them consistently on that, it may become our species' resolution of the Fermi paradox.

<comment><USER14> It doesn't seem particularly fraught with ambiguity? We know what the composition was going back many hundreds of years. Presumably it would not be hard to agree something like, "OK we target the pre-industrial revolution composition" and that would be that.

<comment><USER15> > …presumably it would not be hard to agree…

This seems like a particularly bold claim given that we currently live in a political climate where we can't even seem to agree on basic matters of reality.

</comment></comment></comment><comment><USER8> We should remember that CO2 is an essential fertilizer for plants and phytoplankton, all of which _thrive_ when there is much more CO2 in the atmosphere. Their photosynthesis processes evolved in and are ideal for an environment with CO2 concentrations at least 5-10x the current levels.

 _At or below 150 ppm of CO2 in the air, all land-based plants would go extinct._

<comment><USER9> Geologist here. This is misleading.

Yes, CO2 is what plants eat, but it doesn't tend to be the limiting nutrient very often on Earth today. For the ocean (where 50-85% of photosynthetic oxygen production, and equivalently carbon burial, happens [1]) there are actually maps of this [2], and you may note that CO2 does not appear. On land, it's usually water, nitrogen, or phosphorus [e.g., 3].

Accordingly, there have been many studies on CO2 fertilization, but since it's not the limiting nutrient it doesn't tend to have much of an effect [e.g. 4]. At best there are benefits for some plant species in areas where water is the limiting nutrient, since higher CO2 means plants can keep their stomata closed more [e.g. 5], but even this is a bit of a mixed bag since dry places tend to get hotter and drier under global warming.

[1][https://en.wikipedia.org/wiki/Phytoplankton#Oxygen_productio...](https://en.wikipedia.org/wiki/Phytoplankton#Oxygen_production) [2] [https://media.springernature.com/m685/nature- static/assets/v...](https://media.springernature.com/m685/nature- static/assets/v1/image-assets/nature08101-f1.2.jpg) [3] [https://nph.onlinelibrary.wiley.com/doi/full/10.1111/j.1469-...](https://nph.onlinelibrary.wiley.com/doi/full/10.1111/j.1469-8137.2012.04116.x) [4] [http://www.pnas.org/content/early/2016/12/07/1610156113.shor...](http://www.pnas.org/content/early/2016/12/07/1610156113.short) [5] [https://nph.onlinelibrary.wiley.com/doi/full/10.1111/nph.124...](https://nph.onlinelibrary.wiley.com/doi/full/10.1111/nph.12459)

<comment><USER8> Biologist here. I have a simple question in response to your disinformation: _What CO2 level is used in commercial greenhouses?_

All scientific, controlled experiments with plants demonstrate conclusively that they thrive (faster growth, larger leaves, increased biomass, larger fruits, less need for water, etc.) at higher CO2 levels than what we have today and than we had before the Industrial Revolution. I encourage people who are intellectually curious and honest to look up the scientific papers on the topic and read them for themselves (you don't have to be a biologist or a geologist to understand the experiments, the parameters, or the outcomes).

<comment><USER16> GP said that CO2 was not the _limiting factor_. I took this to mean that something else is often the bottleneck, such as access to nutrient matter. Presumably in a greenhouse, more CO2 can be used because other bottlenecks are reduced.

<comment><USER9> Well said. Yes, if you provide unlimited water, N, P, and light in a greenhouse then of course CO2 becomes limiting, it's the only thing left!

</comment></comment></comment></comment></comment><comment><USER17> We should remember that we are currently in an ice age[1]. If climatology can be reduced to an effective engineering practice that would be awesome, but we should remember that a frozen Earth will be far worse for most human beings than a hothouse Earth. In the worst case scenarios of Global Warming, the burdens and costs will be largely born by the developed world, both in terms of geographical changes such as sea level rise as well as absorbing migrants from more southerly regions. And the developed world is up to those challenges. On the other hand, when, not if, the reglaciation occurs, it will be devastating to the entire human population of the planet. It would be darkly comical if unintentional human warming were staving off the next freezing period, and we brought catastrophe on our planet by trying to fix it. Humility is called for.

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

<comment><USER18> The worst case scenario is more like a "Clathrate gun" doomsday. While the worst case is improbable, I do believe the priors you use to evaluate the risk and cost of global warming might be a bit optimistic. And it seems contradictory to say that the brunt of costs will be paid by the developed world and then admit that the costs include _the migrant from locations on Earth rendered uninhabitable_. Lastly, you are assuming that the political climate will permit us to deal intelligently, compassionately, and fiscally efficiently with migrants. The current political climate seems to contradict that assumption.

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

<comment><USER17> May as well worry about the solar wind blowing the atmosphere away. That's also possible after all.

It's surprising to me that in a technologically astute and optimistic forum like this one, there would be so much resistance to the idea that engineering solutions to heating would be easier than engineering solutions to cooling. Because anthropogenic or not, the climate is going to change, and keep changing, so either we adapt, we engineer it, or we die.

<comment><USER18> You missed my point. Of course it would be great to have a solution for every eventuality. However, the climate rapidly warming is the imminent danger. And it is the rate of change, not the final value, that is the most worrisome.

<comment><USER17> I didn't miss your point, and on the principle of charity I'm going to assume you didn't miss mine.</comment></comment></comment></comment></comment>


Show HN: AutoGlance is the Hipmunk for Used Car Searches - <AUTHOR> http://autoglance.com/search/#Acura,tl,50,10003

<comment><USER2> This is stupendous! I've done these kind of car searches many times and this is a huge improvement. Seriously wish I had this for my last car search. Well done!

\- The lineup and grouping by price, sort order and "worse deals" are all done right. This is a pretty big deal. Congratulations.

\- The "generations" are excellent data to have. Great value for the user.

\- It would be nice to know that there is a real picture awaiting my rollover or at least a disclaimer on stock photos if that's possible.

\- It's not clear that I should click on the car for more information. I wanted at first to click on the bluish price on the rollover. Maybe just put a little "click car for details" at the bottom of the rollover window.

\- Rounder mileage levels would really help. If there were tick marks on each row for 25K increments, that would be the most help.

\- It would of course be nice to refine the search.

\- Sluggish like crazy at the moment, which I understand.

</comment><comment><USER3> OP: Please note that you can fit a line that predicts price based on the mileage (linear regression). For any car that the actual price is smaller than the one predicted is a good deal - that's what you want to have most visible. Obviously, you can use more variables for predicting the price, but the point is that cars that deviate from the fitted curve are either a bad deal or a good deal and that's where machine learning gives you monetary value on your web service. You could make even one step further give API for other websites to use your "bad deal"/"good deal" prediction engine and set your revenue this way.

[EDIT] The more variables you add the more accurate your model can be. You could even use NLP to extract the narrative about the car. You would disrupt KBB, by providing more user friendly interface. It does not have to be the visuals but just the fact that you can boil down the number of all cars that sell down to a hand full number of cars that deviate from the fitted curve. Even if you are not able to tell whether the deviation makes it a good or a bad deal, you are selecting a smaller number of cars worth looking at than any other website. At least you build a time sever which is worth money, too.

[EDIT2] I think I had an epiphany. The distance from the fitted curve is a buyer's risk. Someone comes to your website and you ask what car and what risk. Some people don't want a good deal, they want a fair deal; they want a car that is priced just right. Others might venture to get cars that are outliers, maybe those car have an engine modification or someone is in a rush to sell. In any case you would have a criteria for searching cars that no one has. KBB gives you the sound and fair deal prices but yours index could be calculated in near-real-time and thus more accurate. All depends how you implement regression model.

Note to self: excellent data mining application with interesting visualization

<comment><USER4> _the point is that cars that deviate from the fitted curve are either a bad deal or a good deal_

And unfortunately, the direction of the deviation doesn't tell you which, because some percentage of those deviating cars will have hidden issues that more than make up for the price difference.

A killer disruption would be if every car seller was rated on customer satisfaction based on the 12 months of car ownership following the sale.

</comment></comment><comment><USER5> This really distills the car search information down to exactly what I want. Presented in such a way to where I get a feel for what the meta trends are, as well as the best/worst deals (or other anomalies). Very nicely presented!

Feature Requests:

\- The ability to search for sub car models (Subaru Forester XT vs Subaru Forester), it looks like some higher end models might be filtered as worse deals at the moment.

\- It would also be nice to have a free text field to search for other misc specific car features in the listings.

</comment><comment><USER6> The "X is the Y for Z" line only works if Y is really popular and the whole analogy is easy to get.

In this case, I don't know what Hipmunk is...

<comment><USER4> Most people here do know what Hipmunk is, I think. Hint: <http://www.hipmunk.com/>

<comment><USER7> Do I have to go figure out what Hipmunk is the _____ of to understand it too?

</comment></comment></comment><comment><USER8> Great analogy. Wonderful presentation.

I've been using autotempest.com to search across several sources but it is like rocks to a hammer when you compare the UI.

For rare makes (Triumph, Fiat, Delorean) I would like the ability to search _only_ by make and for much larger radii. The only Fiat showing is the new 500, but there are plenty of older models available across the country.

<comment><AUTHOR> We do indeed have the ability to do this, but we decided to temporarily restrict some features to help ease the load on our server today (most notably the maximum search radius of 200 miles).

</comment></comment><comment><USER9> Very cool! Not sure where the data is coming from, but no results near my ZIP code (95129) for Acura NSX even though there are plenty on AutoTrader and Craigslist.

Having attempted the creation of a number of flight search products I am sympathetic how hard it is to get this sort of data - you either pay lots of money for it or you screen-scrape. Ick.

But, overall, awesome!

</comment><comment><USER10> This is really great. As a suggestion I would put the prices rows (From 8K, 12K etc) outside of the grid and the grid will just contain information of the current car, being easier to eye scan. X axis: Kms/miles Y axis: Price For the tooltips saying ("14 cars that are worse..") that could be on the right side. But not sure about this one.

</comment><comment><AUTHOR> Sorry to all who are having issues using the site, our server is getting killed right now. We're doing our best to keep the site running, here is a screen shot in the mean time: <http://minus.com/m5EvCsoTv#1>

</comment><comment><USER11> Nice work.

My suggestion would be the ability to add a simple tag next to each vehicle. I could then scan the vehicles and mark which ones are off the list or I should follow up on.

</comment><comment><USER12> In canada auto trader rules: they seem to have every car for sale listed, both by dealers and private. Its nice to only go to one place, but will these data owners pull out on you?

</comment><comment><USER13> I select Make, then Model just holds on "Loading..."

</comment><comment><USER14> Doesn't seem to work, at least in my area. I'm getting zero results on some pretty common cars.

</comment><comment><USER15> Really neat interface, but all of the cars I clicked were no longer available.

</comment><comment><USER7> What's the reason for not offering more scope limiters?

</comment><comment><USER16> What is the hipmunk for car insurance again?

</comment><comment><USER17> Do you have an email you can be reached at?

<comment><AUTHOR> kapgoals (AT) gmail(dot) com

</comment></comment><comment><USER18> unable to view the site

</comment><comment><USER19> nice..saves lots of my time getting a good car :)

</comment><comment><USER20> wow, this is awesome

</comment><comment><USER21> This is great! I am in the used market at the moment. But, I am not looking for one specific make and model of car. I am trying to spend 4k or less and I have some parameters like mileage, must have a clean title, etc. So, the search experience is a bit too rigid -- most places where I can select one, I'd like to select many. But the results display is way, way better than anything I have used.

Lastly, I feel like a lot of cars (at least in the price range I'm looking) are sold on craigslist, which isn't used as a source here, for good reason I'm sure.

<comment><AUTHOR> We are definitely going to tweak the interface to give the user more freedom to do exactly what they want. What we've launched here is definitely an MVP, there are a number of really great features that we're working on but didn't feel ready to implement them at this point.

As for sources, we are definitely going to expand a lot; we felt that what we have now was sufficient for launching.

</comment></comment><comment><USER22> I've been working on almost exactly the same project, and a very similar way of displaying the best deals.

The main roadblock is not the UI, but the car data source. It looks like he is parsing other sites, and displaying their data. This is illegal for most sites, unless he uses their API or has a deal with them.

</comment><comment><USER23> What data are you using?

...sorry if there's a faq, still offline

</comment><comment><USER23> What data are you using?

<comment><AUTHOR> At the moment we're just scraping. Hopefully we can get some APIs worked out in the near future.</comment></comment>


Why I write plain JavaScript modules - <AUTHOR> https://ponyfoo.com/articles/why-i-write-plain-javascript-modules <comment><USER2> My ongoing frustration with code reuse in general is that the code I'm looking to reuse reuses other code that reuses other code that refuses other code that reuses... it's turtles all the way down, and any of those turtles can throw a completely opaque error message that required very deep knowledge of that particular turtle to make any sense of. I applaud, thank, and appreciate the author for going back to basics.

<comment><USER3> Preface: I'm not saying "coupling" is good.

Doesn't npm manage transitive dependencies, just like Maven in Java-land? I sure thought it did. Are package maintainers just not getting their dependencies right? E.g. - "everybody" uses jQuery, it will just be there, I'm not going to list it.

I have only used Node/NPM a little bit at home. Most of my JS work has been some things embedded within larger Java web apps, and my coworkers don't really like JS (they are wanting to do static-OOP where dynamic-FP fits better).

<comment><USER4> An example of a current problem in NPM land, is "peer dependencies". Suppose 30 of your direct and indirect dependencies require one popular, fast moving library, say, React. For safety's sake, and to spare the effort of regression testing, many of these modules specify a fairly conservative version range for their own React dependency. Normally, NPM would just give you multiple versions of React, and each library would get the React version that it expects.

There is a small problem and a big problem with this. The small problem, is that your build size will be unreasonably large. The big problem, is that this React library has internal state - you can't just initialise multiple copies of it, and expect them to share a single state.

Enter peer dependencies. Each library that needs React, demands that the root module, your application, specify a normal depency on React, that satisfies their version range requirements. Clearly, this quickly becomes impossible. So, version mismatch is treated as a warning, not an error, and you (the application developer) learn to basically ignore that warning.

I can think of lots of solutions to this problem, all of which have problems of their own.

\- All libraries factor out their state, so that they are stateless. Now you can load multiple instances of a module, but if they have different major versions, then they are totally going to mess up that state that you are holding for them.

\- Application developer: it is your responsibility to patch your dependencies, and their dependencies, so that they all accept an overlapping range of React versions. But who has time to test 30 modules for regressions?

\- Just build more, smaller, simpler applications. This is where I am right now. I still get version warnings, but it is a little less risky to ignore them.

How do you handle this issue in the Java community?

<comment><USER3> Luck, mostly. However, libraries do tend to fall into 2 categories: small, and big. (yeah, I worked hard to come up with those)

* Small, sharp tools (sometimes) - things like Google Guava "collections" utilities, or the Ostermiller CSV file handling library, which have very small and stable scope.

* Big collections of things, such as Spring or Struts. Regardless of how you feel about these libraries, they do tend to come as a family of interrelated libraries (supplemental components) that get released in lock-step and play nice together.

I dislike the Java language, but I guess it is nice that most of the stuff on Maven Central does tend to be stable.

<comment><USER3> Java-land has been going for about 20 years, and went through a bit of a house-cleaning about 10 years ago around the time the Maven project started.

Javascript, a la Web 2.0, has really only been a serious development thing for about 10 years. It's due for its own settling in period soon, I would imagine.

</comment></comment></comment></comment></comment><comment><USER5> As someone who writes React every day, I'm not sure how the `react-dragula` implementation even remotely constitutes React integration? AFAIK React never made any guarantees about `data-reactid` nor what it means to remove it? It's not a public API and is not even used in the latest React anymore except for picking up SSR'd markup? I have serious doubts and wouldn't go anywhere near this.

Secondly, if you tout "React integration" people are going to want a Draggable component or mixin/HOC or whatever. Making people do things in `componentDidMount` isn't really integration.

That said: yes, it's a good idea to base your framework-specific integration on top of a generic battle-tested library. This however appears to be a bad example of that.

</comment><comment><USER6> I like this approach, but one problem with plain javascript that I haven't heard many people address is testability. A module I am using with angular has lots of calls to setTimeout, but these timed out functions are sometimes not invoked until after a test had cleaned up the DOM in preparation for the next test. The timeout function fires and then throws an error because none of the elements it expects are on the page.

Libraries that set a lot of native key handlers can also be problematic. Native browser key events are a pain to mock, and the same mocking techniques are not available in all browsers. If you want to unit test in all browsers, you have to write some truly hideous tests.

The fact is that a lot of browser API's are terrible, and tools like jquery can help smooth over browser differences and make it easier to test your code that relies on a library.

<comment><USER7> You don't need a whole framework to intermediate events and timers.

One approach is to have a library that you call instead of the native addEventListener, setTimeout, etc. method.

Another is to use something like zones.js which does this for basically ever async API in the browser, and then use test utilities that let you play with time, like flushing all timers, or advancing time by specific amounts.

<comment><USER6> But if you write your library to use those sorts of tools, then you now have a dependency, which the article is arguing against doing.

<comment><USER7> The article is not arguing against dependencies. It's arguing against tying your library to a specific web framework.

</comment></comment></comment></comment><comment><USER8> Why is atoa() being used on arguments? You can pass an arguments object to apply(). It even avoids deoptimization (at least on V8), IIRC. (No explanation at [https://github.com/bevacqua/react- dragula/commit/916c5fe4900...](https://github.com/bevacqua/react- dragula/commit/916c5fe4900eca47c07e139d1e0783ca7c6ba814))

<comment><USER9> This is indeed true for V8 IIRC, but even if it weren't, both arguments.length and arguments[ _x_ ] are safe to use without stopping optimisation, so even a very cautious JavaScript dev can effectively clone the arguments object in a roundabout sort of way and pass it to apply, like so:

        // given a context and function 'func'

        var args = [];
        for(var i = 0; i < arguments.length; i++){
          args[i] = arguments[i];
        }
        func.apply(context, args);

Source: [https://github.com/petkaantonov/bluebird/wiki/Optimization-k...](https://github.com/petkaantonov/bluebird/wiki/Optimization- killers)

<comment><USER8> Right, but passing it to atoa() (unless it's a macro? I didn't check) seems redundant _and_ deoptimizes.

<comment><USER9> Oh yes, you're absolutely right there.

Even if it were okay, it's an absurd dependency.

</comment></comment></comment></comment><comment><USER10> I do exactly this now. I used to write "Angular Directives" but not everything I want to share is in pure JavaScript.

Here are some of my successful pure JS modules:

[https://github.com/mohsen1/json-formatter- js](https://github.com/mohsen1/json-formatter-js) [https://github.com/mohsen1/json-schema-view- js](https://github.com/mohsen1/json-schema-view-js)

If you want to use those modules in any framework you just wrap it in a tiny thin wrapper and I don't have to keep up with framework changes and all that...

<comment><USER2> > but not everything I want to share

Is that a typo? Did you mean "not" or "now"?

</comment></comment><comment><USER11> I agree in general, but in the space of UI frameworks it's hard if not impossible to write good cross-framework code.

Most frameworks have a specific way of rendering the DOM.

In React, manually altering the DOM is an anti-pattern. Even more so if you are using a global store like Redux and/or functional components.

Integrating other "classic" UI code into React is almost always very hackish.

<comment><USER12> Coming from PyQt, I just cannot understand or agree with the idea that React is "the future".

It's nice for some tasks, sure, but it also feels like a big hack.

<comment><USER13> Its very good for most tasks. Makes it simple to create and maintain complex UIs.

<comment><USER12> rerender the entire thing "virtually", diff it, then apply the subset of changes that matter? it doesn't seem optimal in any way to me.

it's great compared to the alternatives in the browser today, but it seems extremely wasteful compared to an unbound universe of alternatives.

<comment><USER13> When in write react code i don't think in terms of diff but in terms of how my ui looks based on current state. Underline implementation can change.

</comment></comment></comment></comment></comment><comment><USER14> Good god, this website design. 1980x1200 monitor and not even the entire _first line_ of the headline is visible on the screen.

<comment> mike-cardwell Ditto here on a 40 inch 16:9 monitor at 3840x2160.

</comment></comment><comment><USER15> I've been advocating this for a while, business logic should not be tied to a specific framework. It can be brought into any framework with a super thin, easy to write/read wrapper.

But UI level stuff, probably should be done in your framework. So Business logic drives state, which your framework translates into DOM.

</comment><comment><USER3> It's hard (not impossible) to avoid this with some user interface code, due to the amount of connected, stateful cruft (hopefully the state is pushed out to the edges, but it has to be there somewhere).

I do appreciate little utility libraries like Ramdajs and Validatejs, though.

This article was a nice reminder to make the attempt to decouple small plugins, though. I like the idea of the base module + alternate framework adapters.

</comment><comment><USER16> Just yesterday I spent 4 hours looking for something that'd let me use DOM queries with map and forEach. I settled on NodeList.js. I didn't want JQuery or Zepto or anything larger than 1 KB, but I also didn't want to write something to do this, something I'd have to copy and paste into the next project.

<comment><USER17> Not sure why you spent 4 hours on that, in addition to the other response there's also this method, which lets you call map on it and also call all the methods available to NodeList (you'd lose access to those if you converted it to an array)

      var classNames = [].map.call(nodeList, (entry) => entry.className)

The 'call' function in java script allows you to specify the "this" in the calling of the function. So we grab the map function from an empty array, and call it with nodeList as "this". You can find out more here: [https://developer.mozilla.org/en- US/docs/Web/JavaScript/Refe...](https://developer.mozilla.org/en- US/docs/Web/JavaScript/Reference/Global_Objects/Function/call)

You could also use that to make a super simple method to allow you to call map on any array like object, then you can import this into your other files:

      function map(arr, callback) {
        return Array.prototype.map.call(arr, callback);
      }

Then call it like

      var classNames = map(nodeList, (node) => node.className);

<comment><USER16> Well, I spent four hours on it because I was also considering the other fancy features of these libraries and playing with them. Which is why this post made me think of yesterday's four hour fancy javascript helper library exploration session.

</comment></comment></comment><comment><USER7> Yet another reason why moving to Web Components will make everyone's life easier. No need for these framework-specific binding layers. It's just DOM.

<comment><USER18> I believe anyone who's spent long enough time across multiple programming backgrounds and looked at the JavaScript ecosystem would understand how solid Web Components are. They're objects, and you fill methods on them. But that's not "revolutionary" enough for this community. There's no flash or wow with it, it's just solid programming.

Also, everyone loves to hate the DOM. It's so "low level."

Additionally, I feel Google tainted the idea of them by making Polymer the face of the standard, rather than letting it stand by itself.

</comment></comment><comment><USER19> > The point in question is that developing a library that specifically targets > a framework is a waste of your time, because when you eventually move on to > the next framework ( this isJavaScript,youwill) you'll kick yourself over > tightly coupling the library to the framework.

How about not targeting a specific language either?</comment>


Feeling Stressed Out? Pinterest Wants to Help - <AUTHOR> https://www.wired.com/story/pinterest-compassionate-search/ <comment><USER2> screw pinterest, it's like a virus, poisoning all my google image searches</comment>


Show HN: Minimal music player, uses YouTube as source - <AUTHOR> https://music.reaper.im/ <comment><USER2> Great work. It'd be cooler if we could add more than one song to the playlist at a time.

Also, a way to share/save playlists would be amazing!

<comment><AUTHOR> working on the sharing and saving part, currently focused on a dev tool of mine.

<comment><USER2> Good luck!

</comment></comment></comment><comment><USER3> Love the minimalism! I'm curious, how do you stream the audio?

At first I thought, maybe you embed the youtube iframe and hide it but that's not how it works. I noticed the orion server in the source, and the link downloads the video, which suggests you redirect the video stream via a middle server?

<comment><AUTHOR> Yeah, there's a simple server that pipes a play stream to the response which is attached to the audio tag</comment></comment>