94-year-old Lithium-Ion Battery Inventor Introduces Solid State Battery - <AUTHOR> https://news.utexas.edu/2017/02/28/goodenough-introduces-new-battery-technology <comment><USER2> I'm scanning the paper really quickly. I'm not a chemist but I do know a thing or two about batteries and the standard caveats apply here:

When they say 3x volumetric energy density, that is the actual energy density, which is energy per liter (normal density is mass per liter). Normally people use energy density to refer to energy per kg. Because this is a solid state battery, it is much denser than normal batteries (which are roughly as dense as water). Solid state batteries are smaller but much heavier and this is no exception. It is 33% the size of a lithium battery, but for the same energy it's about 2.5x heavier. Weight is still a much bigger problem for batteries than size- batteries are much smaller than the exhaust, engine and transmission of a car, but also much heavier.

The main limit on specific energy(kwh/kg) for this battery and for solid state batteries in general is voltage. Li-ion is 3.7v nominal, this battery is 2.5v nominal.

1,200 cycles may seem low, but it is actually very good; around 3x the life of current batteries. This cycle life is the time to degrade to 80% maximum storage, at a certain discharge depth and speed. Current batteries only last 300-400 cycles at their specs, but last tens of thousands at 30% depth of discharge.

Problem with the above: in this particular battery, the chemistry breaks down very strongly after it reaches the end of life. Normal lithium does this too, but not as strongly. This stuff may potentially last longer, but it fails much less gracefully. Not in a dangerous way, but in the same way as a normal car often does; once its broken it'll just work worse and worse until it is barely limping.

The temperature capabilities may seem irrelevant, but they are actually a decent problem for li-ion and are the reason lead acid is still used in cars.

Another interesting possibility for glass solid state lithium batteries is that recycling would be very easy. In organic batteries the electrolyte burns or reacts pretty much no matter what you do, but with glass you can plate and unplate cells. Unfortunately due to specific energy, polymer solid state electrolytes are much more likely than glass (also much cheaper).

Edit: IMPORTANT NOTE: this is NOT a fundamentally new type of li-ion battery! Solid state batteries have been around a while (glass, ceramic and polymer), and have specific advantages but low specific energy and power. This particular implementation is a bit higher power and possibly lower cost, but it's just a little blip of progress. Solid state batteries are a good candidate for the future, but they aren't there yet.

<comment><USER3> So... these are too heavy for use in cars etc, too low-voltage to displace Li- ion in ¿many situations?, but would last a long time?

What applications, if any, would this kind of battery be useful for then?

<comment><USER4> Anywhere you need a small but longer lasting battery and don't care about mass. The primary issue with a larger mass is accelerating and decelerating it. However with the larger capacity, it would be less efficient but perhaps could still lead to longer range in the car if the extra energy stored overcomes the added cost of moving it around. Probably not a good thing but could be useful then in something like an electric race car or something.

Submersibles (which may not care about weight due to ballast anyhow), Batteries for Solar Storage (price dependent likely bad at first), Pacemakers, Hearing aids, once it's invented if robotics outpace man engineered human biology, maybe smart blood.

Perhaps also Nanobots, Active 3d Glasses, Cell phones, Laptops, Tablets, Smart Watches that go for smaller space vs weight.

Outside of that perhaps home appliances like a portable bread machine, or a hand-held wireless electric apple peeler, very small things like a rock that has a hidden microphone / camera in it for spycraft, perhaps a heated travel mug to keep your cider warm, or an electric bowl for keeping great-gravy from coagulating on the dining room table, maybe a warm pie plate because who doesn't like warm cherry pie? Perhaps some sort of autonomous mud tunneling microbots, rather have a large boring machine just let these small guys go and be patient and in a decade or two you'll have your tunnel, electric candles in churches could cut down on unnecessary wax use, and helmet lamps used for stuff like lead mining could also find a use (added neck strain not withstanding). Not sure if the added weight would be too much for a target- practice duck that swam around in a lake or not, but if not, that might be the right answer.

<comment><USER5> I think that in many cases, smaller but heavier with more power is a good trade-off. Think cell phones, cameras, bike lights, camping lights, laptops, etc. while lightweight is a feature for all of these, they're also useless without a charge, so IMO the battery life and size together are more important than weight as long as it's still reasonable. Glass isn't light at all, yet they use that a ton in phones. The iPhone 6S Plus is really heavy and I haven't heard anyone complain about it. The efforts around consumer electronics I've seen in the past 20 years have mainly been about reducing size, with reducing weight as a nice typical side-effect.

This would be really great if it ever hits production, but given past battery progress vs what's actually available, I'm not holding my breath.

<comment><USER6> > The iPhone 6S Plus is really heavy and I haven't heard anyone complain about > it

A significant amount of that weight is the battery, so making the battery 2.5x heavier would make the phone substantially heavier, even with the same overall charge. You'd be hard pressed to sell someone on 'This new phone we made is great, you get the same battery life as before but it weighs 40% more!'

I suppose the question is, in which cases would people be willing to accept a _lower_ charge capacity if their phone could charge to full in, say, minutes rather than hours? I feel as though those USB battery packs that are everywhere these days would be a great candidate; plug it into the wall for a few minutes and you're fully charged, and you can charge anything else from there.

<comment><USER7> >You'd be hard pressed to sell someone on 'This new phone we made is great, you get the same battery life as before but it weighs 40% more!'

It's actually super easy, you just say things like "solid construction", "substantial", and "build quality".

<comment><USER8> > It's actually super easy, you just say things like "solid construction", > "substantial", and "build quality".

"Beats By Dre headphones teardown finds metal parts included just to add weight"

<comment><USER9> I know of a hardware manufacture who used to put concrete into their DVD players to give them that quality heavy feel

<comment><USER10> Are you sure that wasn't to dampen vibrations which might affect (or even themselves be caused by) spinning the disk and movements of the read head? (Same reason there's concrete blocks in the base of a washing machine)

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER11> The greatest travesty in the world right now is there doesn't exist a multi- government 10xManhattan sized project to develop a really really good battery.

It would enable a huge reduction in CO2 emissions(bye gasoline), allow developing countries have stable electrical sources and low cost renewable distributed generation, cut costs(good includes cheap), and enable renewable energy sources to make up a larger mix of our energy production.

Always exciting read about new developments, wish I knew more about chemistry/physics, hopefully we get there sometime soon!

<comment><USER12> Governments cannot invent or develop technology, they only hinder it.

<comment><USER13> .. said literally in reply to a comment about the Manhattan project.

<comment><USER14> GP's post is oversimplistic, but I think there's something there. Maybe it's better stated as, "Governments tend toward invention of things that, in the long term, are destructive and divisive rather than peaceful and collaborative."

If "technology" is defined (or construed) to more closely follow successful human evolution (which I think is reasonable), then weapons of mass destructive are a differently (albeit obviously related) phenomenon and not "technology."

It depends on how you view the age-old political question of means and ends. If the latter grows out of the former, and if governments, as monopoly-holders on initiation of violence, use force as their means, then naturally we can expect things that come from government to grow toward those ends.

</comment></comment></comment></comment><comment><USER15> Is it just me or is Goodenough an amusingly paradoxical last name for an inventor?

<comment><USER16> He's also well known in solid-state physics for the "Goodenough rules" [1] (more commonly called the Goodenough-Kanamori rules, but that has less of a ring to it).

[1] [http://www.scholarpedia.org/article/Goodenough- Kanamori_rule](http://www.scholarpedia.org/article/Goodenough-Kanamori_rule)

<comment><USER17> What's really astounding is reading that, and looking at the dates. He first formulated this rule in _1955_. And he's still working and making real contributions!

We really need to work on greatly extending human lifespans, if for no other reason than to keep people like this alive.

</comment></comment></comment><comment><USER18> The press release says "the researchers' cells have demonstrated more than 1,200 cycles with low cell resistance." That's nice, but rising cell resistance is just one way the battery might cycle poorly over time.

Skimming the actual paper, I don't think they demonstrate 1200 cycles for _any_ parameter. Eyeballing the graphs, it looks like they did charge/discharge testing for maybe 1200 _hours_ (Figure 3a), but with really slow charge/discharge cycles of 10 hours each. Anyone publishing in this space would highlight 1200 cycles of stable cycling in the actual paper, if they had data to demonstrate it. They'd also show off faster cycles if high-rate performance looked good.

Looking at the data the authors _did not_ present in the actual paper, I'm guessing that this battery doesn't handle rapid charge/discharge cycles well. (Their cycling test is at only 0.1C, paper claims "acceptable charge/discharge rates" but does not further quantify it... implication is "not a strength of this design.") It may not have great capacity retention either. I don't see any graphics specifically highlighting capacity retention vs. cycles. So at present I'd call this a solid research effort, but even if it could be commercialized immediately it's not clear that it would be a winner. The demonstrated charge/discharge rate is too slow to be practical for EVs or portable electronics. The demonstrated cycling stability is too low to be attractive for grid tied storage.

People who found this paper interesting may also be interested in this related publication about solid state sodium ion batteries that Goodenough was also involved with: [https://www.ncbi.nlm.nih.gov/pmc/articles/PMC5269650/](https://www.ncbi.nlm.nih.gov/pmc/articles/PMC5269650/)

<comment><USER19> I really wish they'd publish more of the limitations as well in the paper. I wonder how much of it got cut out in editing.

Publishing limitations and negative results that lead to dead ends can help other scientists when they attempt to replicate and improve on tech like this.

<comment><USER18> I agree that publishing negative results would help the whole enterprise of science, but the prisoner's dilemma is pretty clear. I would guess that the authors have been "trained" well enough by publication incentives that they didn't bother to highlight limitations even in their original manuscript. That kind of information shows up in the paper only by absences and implication; it's only informal chats with peers where people talk honestly and thoroughly about the negative results and limitations of their approaches. It's a shame that scientific publication ended up this way. It's one of the reasons I left research to write software.

</comment></comment></comment><comment><USER20> I have put a note in my calendar a year from now, and a year after that to read the story about how these laboratory curiosities could not be made in production quantities.

Something I would really love to see would be a solid state battery that exploited the fact that we can draw silicon features at 7nm. How about a couple trillion equivalents of a FLASH cell which we can drain in rows or fill in rows. Sort of a bucket brigade of capacitors at that point but it would not have any recharge issues and since its just charge flying about no dendrites to speak of. At some point I predict that will become a useful way to build energy storage devices.

<comment><USER21> > story about how these laboratory curiosities could not be made in production > quantities

Why would you just want to be cynical about fundamental battery research? This is how all big breakthroughs happen: in fits and starts.

<comment><USER20> It is more battery breakthrough fatigue. Last time I looked there was something like 17 - 18 battery "breakthroughs" over the last 8 years of which exactly one made it into production for a relatively small (10%) improvement in charging performance.

These laboratory curiosities usually fail because either you can't reliably manufacture the precursor material or reliably make the structures needed at production rates (which translates into the cost of the resulting battery)

It came up in a discussion with some Tesla enthusiasts on the ground breaking of the Gigafactory where I wondered if there would be a break through that would make the batteries the Gigafactory would produce obsolete before they finished building the factory. That didn't happen :-).

As a result I recognize its a really hard slow slog through chemistry which is well understood to change batteries. And you're correct there have been a number of improvements in manufacturing which have resulted in incrementally better batteries and that is all good, but so far, starting with a basic battery and making a new battery that is significantly better, has been disappointing.

</comment></comment></comment><comment><AUTHOR> The researchers published the paper, titled "Alternative strategy for a safe rechargeable battery" in the Energy & Environmental Science journal [0]

[0] [http://pubs.rsc.org/en/Content/ArticleLanding/2017/EE/C6EE02...](http://pubs.rsc.org/en/Content/ArticleLanding/2017/EE/C6EE02888H)

<comment><USER22> Thanks. I wish more science writers would provide a link to the relevant journal article.

</comment></comment><comment><USER23> A comment that I think is relevant in a community of startups that often, explicitly or de-facto practice age discrimination:

This engineer is 94 years old. Few, if any, SCV startups would have hired him. Yet, here we are, he might have just developed the key technology to push electric transportation through the hockey stick curve past the inflection point.

Three times the energy density, many times more cycles, no shorting, high charge and discharge rates. Yeah, this is more than just about laptops and cars, this is about planes, boats, trucks and ships.

Think about that before you reject a 50+ year old. Experience has real value.

<comment><USER24> I don't want to take anything away from Dr. Goodenough, but there is a slight caveat with respect to academia. Older, established, and respected researchers are able to attract large teams of of highly talented people. They are also able to secure funding. It is usual that this leader is given top billing on all papers and press interactions, even if they are mostly coordinating the work. This is good for everybody because the lab can continue to attract good talent and _especially_ it can attract funding. Brilliant young researchers working by themselves in obscurity can't really make much headway because they have neither the man power, nor the money to tackle big problems.

So, while I agree with you in principle, older researchers offer more in academia than just their experience.

</comment></comment><comment><USER25> > Braga began developing solid-glass electrolytes with colleagues while she > was at the University of Porto in Portugal.

Slightly orthogonal to the content: this is why it's important for the US to allow people to come to this country. Continuing research and development with the worlds best gives the US a leg up. Past ease of immigration is the reason the US has led in so many areas, constant flow of new and innovative ideas.

<comment><USER26> Literally no one is arguing to the contrary. The problems people have with immigration into the US typically involve the sheer scale of it, the fact that many people who come to the United States do so illegally, difficulty with integrating, and difference in values from native citizens. Nobody is arguing against small-scale immigration of highly skilled scientists, there aren't even enough of them to make a demographic difference.

<comment><USER27> A few days ago some Indian engineer was shot dead because he "looked Iranian". There is a very strong political reason why people like this killer do what they do.

<comment><USER26> Perhaps I should have clarified: by "literally nobody" I meant "virtually nobody", as in "the number of people who believe that we should accept no immigrants whatsoever is very small and statistically negligible".

</comment></comment></comment></comment><comment><USER28> Interesting footnote: "The UT Austin Office of Technology Commercialization is actively negotiating license agreements with multiple companies engaged in a variety of battery-related industry segments."

I recommend the book "The Powerhouse: America, China, and the Great Battery War"[1], it goes into some detail about the legal issues around (one) li-ion design and Thackary's work with/without Goodenough and attribution.

[1] [https://www.amazon.com/Powerhouse-America-China-Great- Batter...](https://www.amazon.com/Powerhouse-America-China-Great- Battery/dp/0143128329)

<comment><USER29> Since reading the excerpt about Goodenough[0] from the mentioned book, I was waiting when he will finally announce his new battery tech. Good read.

[0] [https://qz.com/338767/the-man-who-brought-us-the-lithium- ion...](https://qz.com/338767/the-man-who-brought-us-the-lithium-ion-battery- at-57-has-an-idea-for-a-new-one-at-92/)

</comment></comment><comment><USER30> I have not examined the article yet but I was somewhat impressed with Mike Zimmermans work: [http://www.pbs.org/wgbh/nova/next/tech/new-damage-proof- batt...](http://www.pbs.org/wgbh/nova/next/tech/new-damage-proof-battery-has- higher-energy-density-wont-explode/)

Yes the linked Nova show has that goofy host but it still pretty interesting and is young adult / kid accessible.

I highly recommend seeing the whole Nova show if you can.

</comment><comment><USER31> Basically, the battery has a lithium (Li), sodium (Na), or potassium (K) metallic anode, a _solid glass electrolyte_ , and an "ink" cathode of sulfur (S8), ferrocene (Fe(C5H5)), or manganese oxide (MnO2) on a copper (Cu) current collector.

So it's not _entirely_ solid. The cathode may have a tiny bit of liquid electrolyte between the glass and the copper.

View a helpful diagram at [http://www.greencarcongress.com/2016/12/20161213-braga.html](http://www.greencarcongress.com/2016/12/20161213-braga.html) .

<comment><USER32> I'm not a materials guy but can this "shatter"? What does this mean for applications that need IP67, battery compartment stabilization?

<comment><USER31> I would guess that microfractures in the glass would impede the movement of charge carriers, even if it didn't shatter outright.

It wouldn't be good for the battery to hit it with a hammer, I think, but that really applies to any high-energy-density battery. Not all glasses are created equal, either. It all depends on the composition and the cooling regime. Some glasses can shrug off small-caliber bullets, and others will crumble under your fingertips.

</comment></comment></comment><comment><USER33> Seams like his age is irrelevant, this is a battery with 3 times the density of Lithium-Ion batteries.

To me it sounds like the biggest breakthrough in battery technology that we have seen in years.

That should be the story.

<comment><USER34> I agree the battery density is the main story here, but you also cannot help but be inspired by the mans age. Just today ironically enough, I was questioning if my age might have meant I was not as sharp as I was, and then this story pops up with a man over double my age, still very active and at the top of his field. Cannot help, but be inspired.

</comment></comment><comment><USER35> I hope when I'm 94 I'm still as productive as this man is

</comment><comment><USER36> Wouldn't it be great if this could get to market. Almost sounds to good to be true. Maybe I missed it but are there any working prototypes out there in a vehicle or some kind of device or is this just in a lab?

You would think there would be folks all over this if it were the case. I wonder what is holding it up?

<comment><USER37> It's taken 25 years for Li-ion batteries to get from the lab to the current level of industrial production. If this technology pans out it will probably take a similar time to do the same - maybe a bit faster given the greater interest in batteries now.

<comment><USER38> I imagine (hope!) that the much larger industry and greater need for large scale commodity batteries (electric cars) can speed this up considerably, and not just a bit.

<comment><USER39> and cheap credit in Europe! Make it happen!

</comment></comment></comment></comment><comment><USER40> An easy-to-consume overview of some potential areas of battery improvement, which briefly mentions solid state.

[http://www.visualcapitalist.com/future-battery- technology/](http://www.visualcapitalist.com/future-battery-technology/)

</comment><comment><USER41> Sounds like John Goodenough wouldn't leave goodenough alone.

</comment><comment><USER42> This may be a silly question to ask, but forgive me, I dont know much about EE or battery technology:

Its my understanding that current batteries found in mobile phones, laptops, etc make use of rare earth minerals which are limited and expensive and only available from big players like China. Does anybody know if this technology also makes use of rare earth minerals?

<comment><USER43> > Another advantage is that the battery cells can be made from earth-friendly > materials.

<comment><USER42> thank you, I totally missed that.

That's awesome!

</comment></comment></comment><comment><USER44> If you are interested in more details about solid state battery design and chemistry: [https://arpa-e.energy.gov/sites/default/files/documents/file...](https://arpa-e.energy.gov/sites/default/files/documents/files/CSESS%20Lee.pdf)

</comment><comment><USER45> There's already a Wikipedia article about solid state batteries. I found it interesting to read that in such batteries, ions are still allowed to move around.

[https://en.m.wikipedia.org/wiki/Solid- state_battery](https://en.m.wikipedia.org/wiki/Solid-state_battery)

</comment><comment><USER46> anyone noticed windows xp in the picture? why people still use windows xp in laboratories?

<comment><USER47> Yes. Labs have lots of old specialized hardware that might only work on XP. Also, the photo might be a few years old, but I can't verify that.

<comment><USER46> got that..

</comment></comment></comment><comment><USER48> Hmm, the article mentioned nothing about the weight. For a medium sized quadcopter, 3 times more energy (given the same weight) means as long as 3 hours of flight time which would make all these drone delivery dream come true.

<comment><USER49> Unfortunately, as hwillis explains in another comment ([https://news.ycombinator.com/item?id=13779143](https://news.ycombinator.com/item?id=13779143)), it's not 3x energy for the same weight, it's 3x energy for the same size. It seems to actually be about 2.5x heavier for the same energy.

</comment></comment><comment><USER50> not trying to be smarmy, i genuinely know next to nothing about batteries -- are li-ion batteries not considered solid state?

<comment><USER51> No, solid-state usually refers to a component that undergoes no mechanical or chemical change while in normal operation; conventional batteries undergo redox reactions while charging and discharging.

</comment></comment><comment><USER52> Sounds awesome. Now the real question, what's the path to mass-production?

If they can pull it off, it'll be a huge game-changer.

</comment><comment><USER53> This sounds like it could be really nice for off grid solar set ups if it was cheap enough.

</comment><comment><USER54> A fantastic article for those thinking they might be "over the hill" :)

</comment><comment><USER55> Will they be making these in Elon Musk's so called 'Gigafactory'. I hope so

[https://www.fastcompany.com/3052889/elon-musk-powers-up- insi...](https://www.fastcompany.com/3052889/elon-musk-powers-up-inside- teslas-5-billion-gigafactory)

</comment><comment><USER56> Is it good John? It's Good enough.

</comment><comment><USER57> So sodium-ion battery grid storage?

</comment><comment><USER58> I am really looking forward to see this in the market. And cell phones that can be used as throwing weapons, that as well.

</comment><comment><USER59> Goodenough? It's great!

</comment><comment><USER60> We really are going to run out of jobs for young people if 94 year olds refuse to give them up.

<comment><USER61> Turns out that occasionally an inventor appears who gains more lifetime experience than over 99.99 percent of their "peers".

This always requires more decades than most people expect.

And some of these technology creators are the kind that can go from nothing to something in only a couple years, not unlike the way a software developer can sometimes go from learning basics to an incredibly effective breakthrough app in just a couple years themselves.

Then you give them decades and it's amazing.

With some of them it's so natural that they get better every year, until there is no way anyone else can compare in only just a single decade or two.

These are the operators who if properly capitalized can create the most jobs.

</comment></comment><comment><USER62> What an absolute hero

</comment><comment><USER63> TL, DR: This tech utilizes solid-glass electrolytes vs today's liquid electrolytes. This apparently brings us:

"at least three times as much energy density as today's lithium-ion batteries"

"greater number of charging and discharging cycles, which equates to longer- lasting batteries, as well as a faster rate of recharge (minutes rather than hours)."

The team lead is Dr. Goodenough, making things better!

(sorry, couldn't resist. that's really his name)

If true, that first point especially sounds awesome!

<comment><USER64> I used to always be excited about new battery tech, but let's be honest: we see nearly these exact claims ALL THE TIME, and they never come to market.

I don't know what's to blame, but I'm to the point of "believe it when I see it."

<comment><USER57> The batteries shipping today are considerably better than the ones shipping 10 years ago.

<comment><USER64> Which feels like normal, incremental improvement.

The news is always game-changing. Instant charging. 3x capacity. Biggest breakthrough in years. Huge capacities for pennies on the dollar. Blah blah.

</comment></comment></comment></comment><comment><USER65> I was watching a Nova episode on batteries and they showed a new type of Lithium Metal battery that used a plastic material that separated the positive and negative halves. The unique thing about this new Lithium Metal battery was that it was not prone to the existing problems of Lithium Metal batteries and did not catch fire when punctured. They even started cutting portions of the battery off with a scissor and it continued powering an iPad.

<comment><USER2> Yup, same principle. The problem all solid state batteries share is that the solid electrolyte isn't a good conductor- plastic isn't great for that. Despite that it's the current favorite for reasons of cost. NB that the plastic is very very special.

</comment></comment><comment><USER19> > Maria Helena Braga

I don't want to diminish what this guy has done, but I hope all the other people involved get the credit they deserve.

The sole inventor is for super hero movies. In reality, there are teams, sometimes just 6 ~ 12, but sometimes dozens of engineers and scientists, grad and undergrad students, that work together to figure out all the little parts to make technology like this work and make it viable.

It's never just the first author, but the next six or so authors on a paper that helped make a project what it is.

All that being said, it's still cool to see research institutions working to make stuff like this.

<comment><USER66> I don't understand, the first 2 lines of the first two paragraphs:

>>>A team of engineers led by 94-year-old John Goodenough, professor in the Cockrell School of Engineering

>>>Goodenough's latest breakthrough, completed with Cockrell School senior research fellow Maria Helena Braga

Further down:

>>>Braga began developing solid-glass electrolytes with colleagues while she was at the University of Porto in Portugal. About two years ago, she began collaborating with Goodenough and researcher Andrew J. Murchison at UT Austin. Braga said that Goodenough brought an understanding of the composition and properties of the solid-glass electrolytes that resulted in a new version of the electrolytes that is now patented through the UT Austin Office of Technology Commercialization.

I understand the sentiment, but I don't think it was needed in the context of the article. And while you don't want to dimish from what that guy has done, in a way you diminish the message of the article by singling out a name that the article did not.

Hope this doesn't come across as overly antagonistic, just thought it was odd considering the article seemed pretty good.

</comment></comment><comment><USER67> 94 tahun Inventor Lithium-Ion Battery Memperkenalkan Solid State Battery

</comment><comment><USER68> Damn

</comment><comment><USER69> John Oldenough

</comment><comment><USER70> And he's still got Windows XP running in his lab, based on the photo. An interesting juxtaposition.

<comment><USER71> Even today, my physics lab has multiple computers running Windows XP or 2000. It's the easiest way to keep running old and sometimes proprietary software. We keep them off the network, of course.

(Coincidentally, our work overlaps with John Goodenough's. He's a legend, and impressively prolific even in old age.)

<comment><USER61> It's not just the software, it's also the instruments themselves.

The most worthwhile function of Windows turns out to be its backward compatibility.

This became most apparent after Microsoft leveraged their software engineering leadership by pivoting into an anti-recycling company to make most of their money.

There are incredible numbers of irreplaceable laboratory instruments made years ago which depend completely on the version of Windows that was "supported" when the instrument was issued.

Since Microsoft has failed at their truly most worthwhile function, it is now necessary to put incredible effort into preserving older versions of Windows and even more difficult to preserve the older PC's. These cheap office machines, which were built to spend as little useful time as possible before progressing into their primary target duty as landfill, as electronics go were built especially crummy, just for you.

Anyway, I'll be restoring a mass spectrometer shortly to operate as designed on Windows 3.1.

Yes, it will cost a few thousand for the PC effort alone, but we're not going to spend 100x that amount to get a new(er) spectrometer just so it will operate using a more modern Windows version like XP or W7.

There is also a great possibility that a brand new instrument compatible with Windows 10 will be completely useless in less than 20 years due to this Windows deficiency alone.</comment></comment></comment>


Amazon to Disable S3 Path-Style Access Used to Bypass Censorship - <AUTHOR> https://www.bleepingcomputer.com/news/security/amazon-to-disable-s3-path-style-access-used-to-bypass-censorship/ <comment><USER2> It's unclear to me why would we expect corporations that are designed to seek only profit to care about issues that are unrelated (at best) to profit. Such as human rights.

<comment><USER3> Totally agree with you, it's like every time we're shocked that these corporations are violating human rights and privacy laws — why is this still shocking and why aren't we spending more time putting laws into place to reduce this?

<comment><USER3> This is a little dated now but I thought it was cool when everyone was praising Bezos for the dubious wage raise. [https://screenshot- magazine.com/politics/why-did-jeff-bezos-...](https://screenshot- magazine.com/politics/why-did-jeff-bezos-really-raise-amazons-wages/)</comment></comment></comment>


Show HN: Simple File Hosting on a CDN - <AUTHOR> https://fast.io <comment><USER2> First time I've seen a Terms of Use clause like this one: "Light patterns, like those which might be displayed when using the Services, may result in epileptic seizures in some people. Discontinue use of the Services, if advised by your physician or you experience epileptic symptoms."

<comment><AUTHOR> I don't think there's much danger of epileptic seizures when using Fast.io, thats lawyers for you. ;)

</comment></comment><comment><USER3> Hrm, I've been using Netlify for static site hosting, and the ability to push from other cloud storage might actually make me want to switch, or at least try this out.

For small static sites, I really feel like it's overkill putting them in a repo or having to drag the "whole site" in everytime from a zip file or folder. Especially for small incremental changes that happen often.

If my understanding is correct, I can have a folder in another cloud storage service (or even on my PC), that when I change a single file there- Fast.IO will notice that change and publish/replicate it to the live site. That's pretty neat.

<comment><USER4> Yes, that's exactly right! As we were developing the early versions of our homepage that's exactly how we used it. I just synced down a Google Drive folder and hacked away on code and images. Derek could check out the progress anytime he wanted by visiting the URL. Basically, our homepage was always live while we were developing it - great for our MVP.

Now that the homepage codebase is more mature and we have more people working on it, we just created a GitHub repo _in_ that same folder. Now whatever I'm working on is deployed to fastdev.imfast.io and then when I commit to the master branch of the repo, it's synced to fastio.imfast.io (which is connected to our domains Fast.io, Fast.app, Fastio.com etc..). I have a password- protected private dev site, but I'll keep that one to myself for now :D

<comment><USER3> Great! Thanks for the reply. This sounds like it just might fit my needs exactly :) I'll give it a trial run here soon

</comment></comment></comment><comment><AUTHOR> Hey HN. I created Fast.io as a workflow tool for file hosting. Instead of pushing files to S3, and configuring CloudFront, I wanted more of a "syncing" experience, like Dropbox. The other problem I wanted to solve was log parsing; in other words, I didn't want to log parse. So Fast.io parses the logs for me and sends them right to Google Analytics.

It works as you would expect, and supports files up to 1GB at a price lower than S3/CloudFront.

It's been a long time in the making, I hope you like it!

<comment><USER5> How is this different from Netlify? I've used Netlify as a CDN before, which syncs from git repository. I'm trying to understand when I'd use this service.

<comment><AUTHOR> Hi, a good question, I had a chance to attend the latest JAMstack event in SF, and Netlify is a great product. We aren't trying to compete with them. At a technical level, Netlify is a "build" up platform, and we are a CDN down platform.

Netlify takes a snapshot from VCS and performs a build process. This is imaged into a container and then Netlify has their "CDN" in front of it.

Fast.io is an origin, so processing is largely event driven, pulled on demand, cached on our L2 cache, and pushed to the edge. It's a more traditional CDN model.

There are lots of practical differences. 1) We don't have a build system. 2) We have much larger file limits, up to 20GB. 3) We focus on object analytics, not through our own UI, but by integrating with Mixpanel and Google Analytics. 4) Netlify optimizes content in the build process, we optimize as data passes through. The list goes on.

Netlify also charges a lot (the price just went up) $1000 for an "Enterprise" CDN. We are built around them.

More practically, we focus on object storage and distribution, which is great for files but not for site builds.

It's been a long day, I hope that answered your question.

</comment></comment></comment><comment><USER6> Looks very nice, more competing companies in this space is nice. I mean there are not that many and it seems only netlify is innovating in this space.

Am i wrong or is the very slick website based on a theme? I could guess i have seen it before.

<comment><AUTHOR> Thanks for the kind words. I would say we are not trying to compete with Netlify. See: [https://news.ycombinator.com/item?id=21590512](https://news.ycombinator.com/item?id=21590512)

To answer your question about a theme, see: [https://news.ycombinator.com/item?id=21590473](https://news.ycombinator.com/item?id=21590473)

</comment></comment><comment><USER7> Congrats on the launch. This is a very beautiful landing page. Did you use a landing page builder or is it all hand-coded?

<comment><USER4> Hi, thanks for the kind words! I'm Tom, co-founder of Fast.io. We started with a basic Bootstrap template and then heavily customized it (hand-coded). I'm really glad you like it! We've agonized over the messaging, illustrations, and animation quite a bit. I'm sure we still have a lot we can still improve but we're really proud of how it came out.

Actually, I should mention that it was really interesting to build our homepage on our own platform. We started out roughing it in really quickly in a shared Google Drive folder that deployed to a public URL ([https://fastdev.imfast.io](https://fastdev.imfast.io) for example) then, once we started to have more people working on it and required version control, we switched the site over to GitHub and started deploying there. It's a little mind-bending to just hit save and watch a public site update.

<comment><USER8> This looks like a really cool product!

I just have to say though, this landing page is incredibly pretty. Anyone involved in its design should be proud. I really like it. It renders beautifully on both my mobile and desktop.

<comment><USER4> Thanks again!! Really appreciate it! It was definitely a team effort.

</comment></comment></comment></comment><comment><USER9> So do you have some arrangement with Cloudflare to satisfy the the "Limitation on Non-HTML Caching" part of their terms?

<comment><AUTHOR> Hi, yes, we contract with CloudFlare and Akamai for CDN services at scale, and package them in a SaaS service that provides the rest of the stack. There is no Non-HTML caching limits for us. We do have a 1GB file limit on CloudFlare and a 20GB limit on Akamai. Thanks for your interest!

</comment></comment><comment><USER10> Is this static only? Can this host WordPress sites?

<comment> e-moe it's static only. wordpress will not work. though you can use javascript logic that will be evaluated in browser

</comment></comment><comment><USER11> I like the Google analytics integration. I wish other providers would add this feature too.

Are there any open source tools that you can use to parse a log and perhaps batch-submit to Google analytics?

</comment><comment><USER12> So this is CDN reselling with ease of use added?

<comment><AUTHOR> Hi, not so much CDN reselling as providing a stack that fills out everything under the CDN.

We terminate the origin by syncing from an existing Cloud Storage (Dropbox, Google Drive) or Version Control System (GitHub). We also automate the analytics end by parsing the logs that would normally be in raw format.

The idea is focused at the same use case where you would put content on S3 and pair it with a CDN, our product is just easier to use, faster to setup, and at a comparable or lower price point.

Thanks for your interest!

</comment></comment><comment><USER13> congrats, the product looks great!

<comment><AUTHOR> Thanks so much, we appreciate your support!</comment></comment>


New chat app harnesses Ethereum to send private messages - <AUTHOR> https://decrypt.co/34858/new-chat-app-send-private-messages-blockchain-ethereum <comment><USER2> Love it! Portability is definitely something needed in messaging, just like your crypto funds stick with you in various wallets.

</comment><comment><USER3> Congratulations Unstoppabledomains! This is a great feature! Decentralised web & chat moving a lightning speed.

</comment><comment><USER4> Love the ease of use, the chat feature is a first in blockchain. Thumbs up Unstoppable Domains.</comment>


Show HN: A fun way to follow football games - <AUTHOR> I often don't have time to watch games that interest me, so I built a site that lets you step through each play at your own pace.
You get to see the game unfold without the 'spoiler' that occurs when you're constantly shown the live status.  It's pretty fun - even if it's no replacement for watching the real thing!
Main link: http://www.replayray.com/
A link to Thursday's NFL season opener: http://replayray.com/app/game.py?type=nfl&id=2017090700
NOTE: Most of the week 1 games on the front page aren't clickable until they start tomorrow.  The season opener, which is final and clickable, is at the bottom. <comment><USER2> Where do you get the data for this?</comment>


Recombinant E. coli as a biofactory for nanomaterials - <AUTHOR> http://www.pnas.org/content/early/2018/05/17/1804543115 <comment><AUTHOR> "Capable of producing 60 different nanomaterials including metals, metal oxides, and quantum dots" Woaw!</comment>


Build yourself a Linux - <AUTHOR> https://github.com/MichielDerhaeg/build-linux <comment><USER3> Building a Linux distro from scratch has been one of the most tasking projects I've attempted. There are two phases: the frustration phase, and the tedious phase. Bootstrapping it is an incredibly frustrating process - I restarted from scratch 5 times before any attempt ever got to the tedious phase. The tedious phase never ends. You have to make hundreds of packages to get to a usable desktop system. I've made 407 packages and I still don't have a desktop to show for it (I'm hoping to get sway working tomorrow, I think I have about 30 packages left).

Still, I've finally gotten to a somewhat practical self-hosting system. My laptop runs it on the metal and all of the infrastructure (website, bugzilla, git hosting, mirrors) is on a server running my distro too. It's taken almost a year of frustration, but it's very rewarding.

<comment><USER4> I'm just curious: In what way is it rewarding? Just for educational purpose? Or anything else? Or is it just a hobby? I mean, you are probably investing a lot of time into this. This time you could spend on other things instead.

I see the educational purpose. Although you probably get similar experience/understanding/education if you use something like Gentoo and you would have to invest much less time because all the nasty corner cases are already taken care of.

<comment><USER3> It's rewarding because I finally have a Linux distro that's designed the way I want. I started making this because I wasn't satisfied with anyone else's offerings.

<comment><USER4> Can you say what is different in your distro than in any other distro? And you think that no other distro could have been extended/fixed to get what you want? Do you consider that this is useful for anyone else? In that case, you really should publish your work and write about it.

<comment><USER3> Blog post: [https://drewdevault.com/2017/05/05/Building-a-real-Linux- dis...](https://drewdevault.com/2017/05/05/Building-a-real-Linux-distro.html)

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

</comment></comment></comment></comment></comment><comment><USER5> I really wondered what's so special about this project that aims to achieve what probably more projects aimed to achieved than there are lines of code in the kernel.

It's not the goal, it's not the OS. But the documentation is a sight to behold! Very clear, detailed, interesting writing style, and it puts together quite a few frustrating topics in a simple, structured matter. Wow and kudos! Keep on writing docs, please!

<comment><USER6> Your kind words are much appreciated. Many people seem to indeed be missing the point. I wasn't trying to create a new distro, I'm just trying to teach people in a way so that it would just take a few hours of your time.

</comment></comment><comment><USER7> Both this and LFS reminds me that Linux makes sense until you get the DEs involved. At that point shit just sprawls all over the place as there are no longer any notion of layers.

<comment><USER8> Back in 2002 I ran LFS for a semester and a half. Then I got tired of saving all my ./configure flags and switch to Redhat and gained a respect for package management. :-P Eventually I started using Gentoo.

Still, I'm really glad I built and ran an LFS for nearly a year. It helped me build a really in-dept knowledge of Linux that's helped me as I later moved into embedded development.

Today I still use Gentoo (which feels like LFS with package management) and Void and would recommend either for Linux devs.

<comment><USER9> I did exactly the same in 2005. I even wrote my own init scripts, so I really understood a lot what's going on at startup time. Linux was quite simple at that time. I could write my own init, if I wanted. Unfortunately now this knowledge is obsolete. Systemd is a complex beast which uses a lot of arcane techniques, I'm hardly understanding it. chroot was a really simple concept, but nowadays people use containers, and they are much more complex than chroot. Logging is complicated. In the past I could try to load and then mount partition from livecd or another OS and read logs, now I don't know how to do it. Init scripts were simple bash scripts. They were verbose, may be buggy, but after all they were just bash scripts and every Linux user knows bash, so every Linux user could write or modify init script. Now systemd uses its own format, I'm spending hours every time I need to write new service or timer for RedHat. SELinux is just so complex. I know about UNIX permissions. They are so simple and elegant. I'm using them everywhere, when I need security. I could explain them in 2 minutes. SELinux has books. I have those books in bookmarks, may be I'll read them sometimes. But until then, I just use copy-pasta from internets to solve my tasks, like allow ssh to listen at non-standard port. I don't think that it's good, that I have to run some random strings on my computer from root without fully understanding what they are doing. SELinux has binary compiled configurations and some encrypted logs for tools to decipher them, what a mess! Sometimes I just disable it to get things done.

Don't get me wrong. I think that Linux looks more professional, more robust, especially for system administrators, who can devote their lives to learn about those systems. But for hobbyists, who doesn't have a lot of time, Linux became much less transparent.

May be if I didn't have that prior knowledge, it would be easier to learn those things from scratch. But I doubt it.

<comment><USER8> I've had to learn apparmour, which isn't too bad and a lot easier than SELinux (maybe not as powerful).

Systemd is a religious argument at this point, but if you want simplicity check out Void. It uses runit and I love it. It's incredibly simple. Startup files are often less than 4 lines. I don't really like systemd either, but I will admit, as a package maintainer, it does make packaging a lot easier/universal. It'd be nice if there were drop in replacements for systemd that uses the target files for services and trashed everything else. UselessD was a cool project that attempted it, but it became to difficult to maintain. :(

I currently work at a docker shop and I will say, containers are pretty nice. They're better isolated chroots with a lot of cool versioning support. There are pluses and minuses, but overall, I think docker is a nice evolution from chroots. Now all the eco-systems around docker: kubernets, DC/OS/marathon, nomad .. all totally different, proprietary and over-complicated.

<comment><USER10> The nosh toolset can of course import systemd socket, service, and target units into its native daemontools-encore-superset form; which can then be used on a BSD, on things like UbuntuBSD or Debian kFreeBSD, or (in theory) on Debian Hurd; as well as on Linux operating systems.

* [http://jdebp.eu./Softwares/nosh/worked-example.html](http://jdebp.eu./Softwares/nosh/worked-example.html)

</comment></comment></comment></comment></comment><comment><USER11> A similar process is building a custom kernel and rootfs for an ARM device such as the beaglebone. Olimex actually has a good tutorial for their device: [https://www.olimex.com/wiki/AM335x](https://www.olimex.com/wiki/AM335x)

This is only slightly more complicated due to the need to cross-build but I found it fairly easy with qemu-static-arm and prebuilt cross toolchain packages for Ubuntu/ Debian.

The benefit is that you can develop for a target device that is not your PC, so no worry about messing up the bootloader and leaving your PC in a state where you need a recovery CD to fix it and boot. Just get a USB-serial cable :)

You can also try buildroot or yocto, although I had no interest in building _every_ package manually versus relying on Debian's repos.

</comment><comment><USER12> This is almost as complicated as building a Javascript web application.

<comment><USER13> Except that the recommended tools don't change every few months ;)

<comment><USER14> Yeah, pmount, hal, ivman, udisks, consolekit, consolekit2, policykit, upstart, systemd, oss, alsa, pulseaudio, xfree, xorg, wayland, mir, kms, gtk, gtk2, gtk3, qt9, motif, unity, loadlin, lilo, grub, grub2, ghtml, webkit, qtwebkit, webkitgtk, webkitgtk2...

I guess you're right, they change only every few years :)

<comment><USER13> He did say _almost_ as complicated ;)

(Also: QuickBASIC 4.5 forever! Assuming that's the meaning of your nick).

<comment><USER14> Yep, that's what got me started on programming as a kid. And it still has better strings and arrays than C.

</comment></comment></comment></comment></comment><comment><USER15> Have you even looked at the LFS project[1]? And what does your guide provide that LFS doesn't?

[1] [http://www.linuxfromscratch.org/](http://www.linuxfromscratch.org/)

<comment><USER16> Actually LFS teaches you about the whole GNU Userland, getting a kernel up and running with busybox is much easier. This project does just that - <USER2> you the bare minimum.

<comment><USER17> The embedded version of CLFS (Cross-Compiled Linux From Scratch) covers building a musl + busybox system: [http://clfs.org/view/clfs- embedded/x86/](http://clfs.org/view/clfs-embedded/x86/) But the more resources available on this kind of thing the better IMHO, there's not really a one size fits all :)

</comment></comment></comment><comment><USER18> If you are interested in building your own Linux, the LFS project has a lot of detailed information: [http://linuxfromscratch.org](http://linuxfromscratch.org)

<comment><USER19> I see this project as the next logical step beyond LFS. LFS will help you get one up and running from start to finish, but once you do that, you might want to try it a bit more free-form. That's where this project seems to fit in.

<comment><USER20> Certainly you mean the other way around? This project gets you busybox and a kernel, which barely qualifies as "up and running from start to finish", whereas following this doesn't even get you a compiler in the target system.

</comment></comment></comment><comment><USER21> I have a question related to this article, though not directly. If building completely from scratch turns out too cumbersome and time-consuming, what would be the easiest way of building a minimal, fast starting distro with graphical user interface and networking whose only purpose is to run one application on x86 hardware in kiosk mode?

Is there a distro builder for dummies?

<comment><USER22> [https://susestudio.com/](https://susestudio.com/) (NOT REALY WHAT YOU WANT)

You can pick packages and build a distro from browser.

NixOS - You can make one config file to specify how your system should look like. It's easy to make GUI for it.

</comment></comment><comment><USER23> Following this guide will get you something very close to a base Alpine Linuxwith busybox. Alpine is fairly minimal out of the box and even eschews grub for syslinux.

The upside with Alpine is if you need features and packages they are an install away. But if the purpose is to learn about compiling the kernel and how the system initalizes this is a decent start.

</comment><comment><USER24> This sounds like Aboriginal Linux: [http://landley.net/aboriginal/about.html](http://landley.net/aboriginal/about.html)

</comment><comment><USER25> Huge fang on Linux From Scratch myself, after reading this I wonder if someone has tried the same with FreeBSD! Or the Darwin sources released for OSX (.. not talking about dormant PureDarwin project)

</comment><comment><USER26> This is awesome. I've been building almost the exact same project, along almost the same timeline (based on the commit history). Mostly an excuse to learn more advanced Bash, and Linux Internals/Features I've never had a good excuse to explore. Gonna release next week. Hope I get as warm a reception. Kudos on an awesome project!

</comment><comment><USER27> I am following this guide to build a kernel. But it seems like that instead of getting the headers from the kernel source they are using a github repository which only contains the headers to save downloading time. All fine and dandy if the latest commit to this repo wasn't from 3 years ago!!

</comment><comment><USER28> I remember when HOWTOs were actually maintained over time so their instructions were up to date. Blogs killed HOWTOs.

</comment><comment><USER29> Let's branch to add : sysvinit/BSD, init, OpenRC, upstart, systemd, SMF, launchd, Epoch, finit ..

[https://wiki.gentoo.org/wiki/Comparison_of_init_systems](https://wiki.gentoo.org/wiki/Comparison_of_init_systems)

</comment><comment><USER30> Awesome! Good job. This also helps understand what the distro installer does.

</comment><comment><USER31> Seem neat to learn, but for something maintainable, LinuxKit seems interesting.

</comment><comment><USER32> This is an awesome write-up. did not know losetup can do what kpartx does now with the option -P, I did similar things in the past but this is a good update for me.

</comment><comment><USER33> I've crashed and burned a couple of times trying to complete LinuxFromScratch, so I may give this a go - It seems a bit clearer on the core steps.

</comment><comment><USER34> Well, I'd use [http://linuxfromscratch.org/](http://linuxfromscratch.org/) for that matter...

<comment><USER29> LFS is infinitely more involved and am not sure for good reasons. I don't like to say it because it's someone else project but I feel important parts are missing, format is wrong, and without BLFS the goal is only half realized.

</comment></comment><comment><USER35> Has anyone used Tinycore Linux? [http://tinycorelinux.net/](http://tinycorelinux.net/)

</comment><comment><USER36> Would be cool to port this to Nix package manager machinery (i.e. make this kinda an alternative to NixOS).

</comment><comment><USER37> I feel like just reading Nixpkgs is probably just as edifying, tbh.

</comment><comment><USER38> Beautiful.

</comment><comment><USER39> I don't think this is much useful. You should check out the linuxfromscratch.org</comment>


The only startup founders who can embrace failure are the privileged ones - <AUTHOR> http://qz.com/772173/the-only-startup-founders-who-can-embrace-failure-are-the-ones-privileged-enough-to-survive-it/ <comment><USER2> I would have to respectfully disagree. Many, many successful entrepreneurs come from modest backgrounds, with little or no education. What they all have in common is the belief that hard work developing their business and laser focus on their customer's needs will make them successful.

I often feel sorry for privileged young people - I think they have it much harder in some ways. They sometimes live in a bit of a bubble due to their upbringing and that makes it hard for them to understand the mass market. Also, they might have a harder time developing a work ethic and grit if they did not need to go to work at a young age or face adversity.

The whole tiny VC funded startup club in SV may be an exception to this rule, but vast numbers of successful entrepreneurs in the USA never get a penny of VC $ and find some way to startup themselves.

</comment><comment><USER3> I agree with the gender disparity, but not race. The Kaufman Index of Startup Activity claims that more startups are from male entrepreneurs than female ones, but white entrepreneurs account for a lower portion of startups in 2014 than 1996.

The author cites studies on self employment in the United States. I think there is a difference between being self employed and an entrepreneur. For example, I can be a self employed contractor, but not aiming to grow a business as an entrepreneur would.

When it comes to tech startups I could see the industry remaining white and male dominated. Access to angel investors and VCs from a privileged network increases the probability of obtaining funding for a new company. This is especially helpful as more tech entrepreneurs are in school or recent graduates. If I am around college age trying to get a tech startup off the ground, can I find an investor without existing social contacts? Yes, but it will be much more difficult for me than the kid with the contacts.

</comment><comment><USER4> This is why I advocate for what I think of as a zero marginal lifestyle.

If you can create a Passive Tiny House with renewable energy sources then you've a safety net while you work on your crazy schemes. I estimate that shall take 25k - 50k per person which is doable.

Should communities of geeks do the same thing you could have a hackerspace and central utility hub too. Under such conditions a very low income can provide you with sustenance and net access. Suddenly putting lots of project oriented people in one place to rub shoulders becomes economically feasible for a trivial amount of capital.

I don't think it has been done but I like this idea. It reminds me of that blueseed venture thing they were trying on that ship off the coast of San Francisco.

<comment><USER5> >If you can create a Passive Tiny House with renewable energy sources then you've a safety net while you work on your crazy schemes. I estimate that shall take 25k - 50k per person which is doable.

That sounds good on paper but when push comes to shove a an apartment in a "bad" neighborhood or mobile home in a park or middle of nowhere has substantially cheaper up-front costs and similar day to day costs. The downside is that you can't make smalltalk about that lifestyle, or at least not amongst the middle and upper class you can't.

<comment><USER4> Oh I know all about bad neighborhoods and cheap rents. They are cheap for good reason.

I have twice left a house share because it was becoming frankly unsafe to live in. In the first instance I should have taken the hint that the house next door had not burnt to the ground by accident (several broken windows later I moved out!) and the second time a lunatic car thief threatened to kill me. Hard to concentrate under the circumstances.

Having better company around you in a geek community is well worth it! Arguments about functional programming or open source are significantly less likely to result in death or injury. It is also nice not to have your life mortgaged to some [expletive].

The concept is that each person kicks up 25k - 50k depending on whether they build their own with other fellow TH builders or get it done for them. Common utilities to be installed and paid for can be paid back via loan or some other arrangement. For power I would recommend actually making a micro hydro station together, it's not that difficult and you could easily supply dozens of THs.

Cost of land can be small since you could be in a rural area, with periodic trips or public transport nearby to a city.

The reason why I'm calling this 'marginal cost' is important. It is not free (but monthly bills would seem miraculously low in comparison to most people's situation). It is just that if you do it you're unlikely to become indebted/homeless or not have the funds to stick at your project long enough. Lots of interesting ideas need considerable time and patience to gestate. VCs operate within a relatively narrow window of opportunity in time, and this is a concept that could open up more long term possibilities.

The only threat to this I see is that having some pressure on your back can be a positive thing, but I feel that is a separate discussion with workarounds possible.

</comment></comment></comment><comment><USER6> I don't think anyone embraces failure. For most startups, failure embraces you. (More like a tackle.) Then you either shake it off and keep moving, or not. Most people who have the balls to do a startup in the first place will go with option #1.</comment>


Idea to Prototype to Kickstarter in 3.5 Weeks - <AUTHOR> http://www.ridiculo.us/?p=820

<comment><USER2> This is fantastic, congrats. If I had an iPhone I'd back it!

If you could do a version for ancient Nokia phones (the kind with monophonic ringtones) I'd be all over it!

Though not sure about the reward tiers. The high-ticket ones just don't sound very appealing... Might have made more sense to have a slightly more expensive tier for your choice of colour, or for two or more bought together.

<comment><AUTHOR> Haha. Not sure how much of a market there'd be for those Nokia phones... although I do miss the original Snake game.

The higher reward tiers are really just there for kicks and grins.

Unfortunately, Kickstarter's newest requirements for design projects don't let you sell multiple copies of a reward. And custom colors are super-expensive (several hundred dollars to set up and run a custom color) to the point where it isn't viable for us yet.

</comment></comment><comment><USER3> And at $25 for some injection-molded plastic, it's no doubt hugely profitable if/when they recoup the initial tooling costs.

<comment><AUTHOR> The if/when is the issue. :)

Those initial tooling costs are steep!

</comment></comment><comment><USER4> Interesting read, but the author needs to ease up on the bold text. Bold text is for key points only and loses its meaning when overused.

I counted 159 words in the summary, of which 85 were bolded (53%).

<comment><AUTHOR> That's fair. I'll try to ease up next time. I can get a little overzealous with my bolding when I get excited.

</comment></comment><comment><USER5> Interesting story. It will be interesting to see if it reaches its goal, how many would you sell if you "sold" it on thingaverse ? How many musicians use this style? Etc.

<comment><AUTHOR> Thanks! We're interested to see what happens as well.

Thingaverse/shapeways are certainly options too, but they don't give the same polished product that injection-molding does.

We're hoping that the WeeWow will expose a lot more musicians to this style. Since traditional talkboxes are expensive ($180 bucks or so) a lot of musicians have heard of talkboxes, but not very many have ever used one. Even if they never record with one, we're hoping the WeeWow will give musicians something to experiment with. There are never too many ways to make cool sounds. :)</comment></comment>


Show HN: Invite to try fiesta.cc - effortless mailing lists - <AUTHOR> https://fiesta.cc/?i=1&s=1drW1z%7CdXHybwS-czt8LYsWHcyBIoHupps

<comment><USER2> Sounds a good concept. Can anyone send email to the created list or just the initial members? What if the list is already created / used by other people?

<comment><AUTHOR> Only members of the list can send an email to the list - since the list names are tied to the sender's address you don't need to worry about uniqueness (ie. my firstname.lastname@example.com is different than your firstname.lastname@example.com)

<comment><USER3> One more thing... what happens if I'm part of two different firstname.lastname@example.com lists? :-)

<comment><AUTHOR> when somebody tries to add you to the second one it'll be automatically renamed (just for you, not for everybody else) to email@example.com - you can then go into the web UI and rename both however you want!

<comment><USER3> Now I'm thoroughly impressed, thanks

</comment></comment></comment></comment></comment><comment><USER3> Mailing list systems are complicated for a reason: the signup process where you have to send a confirmation mail is there to prevent users from unsolicted mails.

How are you going to solve the problem of unsolicted mail deployed through these autovivified mailing lists?

<comment><AUTHOR> We've got some basic spam prevention already in place with some more advanced ideas being implemented soon.

You're right though, if all else fails the welcome email will just end up having an opt-in link.

</comment></comment><comment><USER4> There seems to be a problem with the encoding:

Hi, =?ISO-8859-1?Q?Gabriel_Rodr=EDguez_Alberich?=! Choose a password to use for fiesta.cc:

<comment><AUTHOR> oops, thought that was handled properly. fixing now (if you don't want to wait you can change your name from the "Dashboard" page). Thanks for the heads up!

</comment></comment><comment><USER5> I love the simple landing page. The only thing I'd change are the screenshots. If you add a highlight to the CC textfield for example, it'd more quickly illustrate the point. Centering the object doesn't really put enough focus on it.

Also, you could put more context in the example. Like saying it's for birthday party or for vacation photo's (like Apple does).

<comment><AUTHOR> Thanks! I think those are both great suggestions - I'll see what I can do.

Suggestions like that are really helpful as I am definitely not a designer (IADNAD).

</comment></comment><comment><USER6> Thanks for this, we used librelist.com to create our ML last months, but it was too opened (archives on google, anyone could join) for some people.

<https://fiesta.cc/about> do you use mongodb in the backend?

If so, could you give us more technical details about how you connect your mail server to the DB?

<comment><AUTHOR> Yeah, the other nice thing about this compared to librelist is that you can use any list name you want without worrying about conflicts (since lists are tied to the sender's address).

Yup, using MongoDB to store everything. I will definitely be doing a post discussing the architecture, etc. Follow @mdirolf or @fiesta and you'll see it when it pops up.

The short answer, though, is that I'm running a 3 node replica set. Each mailserver (right now there are 2) is running on one of those nodes.

<comment><USER7> >> Yeah, the other nice thing about this compared to librelist is that you can use any list name you want without worrying about conflicts (since lists are tied to the sender's address).

And that's how clever software is built.

</comment></comment></comment><comment><USER8> Looks great! I think you should rework the testimonials on the site. I don't think your target audience will recognize a Twitter username.

A feature request would be a link to see the full history of the email list. Would be great to be able to add another person down the line and them being able to read up on what topics have already been discussed.

<comment><AUTHOR> Thanks! Yeah I just added the testimonials this morning so they definitely can be spruced up I think :)

Archiving is definitely in the works. It'll be opt-in, per list, that way we still never save any emails by default.

</comment></comment><comment><AUTHOR> I'll be around here to answer any questions about fiesta. Any feedback would be greatly appreciated!

</comment><comment><USER9> Awesome concept. It was about time someone innovated on the mailing list concept.

</comment><comment><USER10> I like how simple this is, but I find the branding a bit off. Nothing is memorable about fiesta.cc, and a .cc domain tells me you may not be serious enough about your business to invest in a better domain.

<comment><AUTHOR> Thanks for the feedback! I was thinking of .cc as a feature, designed to evoke the act of CC'ing an address to create a list. Wasn't a decision made due to lack of seriousness or to cut costs, but maybe still needs rethinking if the CC connection isn't obvious...

<comment><USER10> You certainly have thought about that. It does make sense when you write it. I think with the right treatment you can shape your brand effectively. I think the .cc tld is still obscure enough that you could shape it to mean email 'cc'.

</comment></comment></comment><comment><USER11> Is there a UI that I can use to edit the lists? The whole plustag thing seems tedious.

<comment><AUTHOR> Yeah the plustag thing is really the advanced UI - if you click "List Members" on the bottom of any emails you get from fiesta (including the welcome email), you'll see the web UI.

</comment></comment><comment><USER12> How do you plan to make money? Annoying ads in the emails or some other idea?

<comment><AUTHOR> In the short term, I don't :P. I have some long term ideas, ideally keeping it ad-free forever.

<comment><USER13> Also would be useful for business if I could "private label" the service to work on my own domain name (or sub domain) simply by adding a fiesta.cc mx record to my dns.

<comment><AUTHOR> this is exactly one of the ideas that I want to pursue!

</comment></comment></comment></comment><comment><USER14> Off-topic, but your roommate is my colleague.....all the best :)

<comment><AUTHOR> oh awesome! he is a great guy

</comment></comment><comment><USER15> Great idea, very simple and instantly cross-platform.

<comment><AUTHOR> thanks!

</comment></comment><comment><USER16> Isn't this what Posterous supposedly does? In relation to Yahoo/Google groups, where does list archives go?

<comment><AUTHOR> the defining feature of fiesta.cc (as opposed to posterous, etc) is that list names don't have to be unique - so anybody can make a new list called "firstname.lastname@example.com" without worrying about registering the name or running into collisions.

Right now messages aren't saved at all (for privacy reasons). In the future there will be optional (opt-in) archiving like yahoo/google groups has.

<comment><USER16> Okay thanks. It seems like an interesting concept, something that should be native to Email perhaps. However, outside of this thread, if I visit your site (as an average user), the concept of how it works doesn't seem easy right away. I'll have to play/test to figure it out.</comment></comment></comment>


One sentence per line, please - <AUTHOR> http://rhodesmill.org/brandon/2012/one-sentence-per-line/ <comment><USER2> Or, you can use a diff command which understands word diffs. git has '--word- diff', svn unfortunatly doesn't have such an option, but '<http://www.sable.mcgill.ca/~cpicke/swd/> provides a nice script (there are others). Don't know about mercurial.

I hate working with authors who try to force line breaks into text unnaturally. I have heard many justifications for it over the years, but I find it hard to understand why anyone would do it, other than because their tools (soft word wrap in the editor, word-based diffing) are terrible.

<comment><USER3> The original article did say "In the tutorial, I ask students whether or not the Sphinx text files in their project will be read by end-users."

I certainly would not send a file with 'semantic linefeeds' to _anyone else_. I use markdown quite a lot and LaTeX a little, so I'm happy with

      source file -> formatter -> file for reading

The humble fmt (Linux) deals with a file with 'semantic line feeds' and produces reasonable paragraphs. I think I will try this out as a lot of text editors have line oriented tools. It might be that the result of a lot of rearranging that way will resemble a Burroughos cut-up, but I shall see.

I'm sure someone will come up with a regexp that can take a 'standard' text file and split the lines on full stops and commas to restore an edited readable text file to 'semantic linefeed' source, thus allowing round trip copy editing.

<comment><USER4> > I'm sure someone will come up with a regexp that can take a 'standard' text > file and split the lines on full stops and commas to restore an edited > readable text file to 'semantic linefeed' source, thus allowing round trip > copy editing.

Yes to the first, no to the second. The reason is that the act of recombining lines into paragraphs makes the assumption that lines broken by single linefeeds need to be merged into a paragraph. But in text, a list of items, meant to be read as a list, is also broken by single line feeds, and _must not_ be turned into a paragraph.

One often sees posts here by beginners that include a list of items, but the rendered version assembles the list into a (typically unreadable) paragraph. More experienced hands know to break the list up with double linefeeds to defeat the "intelligent" reformatting algorithm.

The bottom line is that a recombining algorithm cannot distinguish a list of items from a paragraph of individual lines. The act of breaking text into lines loses information irretrievably.

Allow me a prediction: All these conventions that break text into individual lines and then try to reassemble them, i.e. this forum, the e-mail convention, and a thousand other examples, will eventually be abandoned in favor of leaving the text alone. This will happen when people realize they're throwing away information that cannot be recovered.

When I wrote Apple Writer in the late 1970s, the first change I made to common practice was retain the paragraph structure people naturally used in entering text (even though the displayed text was broken into lines on word boundaries). At the time, this was a bigger departure than it is now, and it helped make my program successful. But if I had been told then that people would still be defending the practice of breaking text into individual lines 35 years later, I would have laughed out loud.

<comment><USER3> point taken for plain text files, but I use markdown so list items have asterisks at beginning of the line, so I have a pattern to distinguish list items from flowing text.

"But if I had been told then that people would still be defending the practice of breaking text into individual lines 35 years later, I would have laughed out loud."

Laughing is good for you! If I read you right, you invented the soft line wrap? Excellent!

</comment></comment></comment></comment><comment><USER4> > One sentence per line, please

I beg to differ: One paragraph per line, please. The natural lexical unit is not the sentence, but the paragraph. These three sentences belong together as a unit, and should be separated from other paragraphs by a double linefeed.

If someone wants to later break paragraphs into separate sentences for some reason, it's child's play, and that option is implicit in this formatting. But if someone wants to reassemble individual sentences into paragraphs, as anyone knows who has tried to reassemble lines into paragraphs (as with an e-mail in its delivered form), it's nearly impossible to get right.

Complete thoughts reside in paragraphs, groupings of sentences, not in the sentences. One paragraph per line, please.

<http://en.wikipedia.org/wiki/Wikipedia:Dont_use_line_breaks>

A quote: "Do not use manually entered hard line breaks within paragraphs when editing articles."

A long list of justifications follows in the article.

<comment><USER5> Diff and merge algorithms are line-oriented. If a whole paragraph is on one line, and I edit one word, then the diff consists of the whole paragraph, which is bad. Some tools are able to do word-by-word diffs, as mentioned below. But none are able to merge correctly in the scenario where two branches have each edited one word in the same line.

I rarely edit Wikipedia so I don't know what its diff algorithm does. But I'm pretty sure it doesn't do any merging in any scenario, so that partly explains why one clause per line would not help there. That's quite different from Sphinx and TeX, which are usually stored in merge-capable version control. I think all of Wikipedia's justifications are specific to the case of editing in a text-box on the web and without diff/merge algorithms.

> if someone wants to reassemble individual sentences into paragraphs, as > anyone knows who has tried to reassemble lines into paragraphs (as with an > e-mail in its delivered form), it's nearly impossible to get right.

The post proposes a single line-break after each clause or sentence, and then a double line-break after each paragraph. TeX and Sphinx do the right thing in those cases.

<comment><USER6> > Diff and merge algorithms are line-oriented.

No, diff and merge algorithms are symbol-oriented.

For reasons that are as historical as they are technical, most diff and merge _programs_ choose to break documents up on a line level of granularity in order to produce the symbols that are passed into the algorithm. But that's a design decision, not a technical one.

A diff/merge program that operates at a word level of granularity should be just as capable of handling two words edited on the same line as a line- oriented diff program is of handling two lines edited in the same function.

> The post proposes a single line-break after each clause or sentence, and > then a double line-break after each paragraph.

It's a lot easier to rewrite the typographical conventions a piece of software conforms to than it is to rewrite the typographical conventions that millions of humans grew up using. Teaching the diff/merge program to recognize that CRLF isn't the only text boundary out there would achieve the same effect* at much lower cost.

*I realize that abbreviations complicate it somewhat. I'd submit, though, that if a basic diff/merge program is being relied on too closely in a scenario where that actually causes any consequential problems then the real error might be between Mr. Diff User's keyboard and chair. For normal diff usage 'failed' symbol boundary determinations like that are fine, the same as how a traditional line-oriented diff program doesn't critically suffer from the way it would interpret me inserting a carriage return into a line of code.

<comment><USER5> > No, diff and merge algorithms are symbol-oriented.

Point taken, and as soon as someone puts word-by-word merging into svn or git, I'll change my opinion.

> I'd submit, though, that if a basic diff/merge program is being relied on > too closely in a scenario where that actually causes any consequential > problems

[EDIT removed some response -- maybe "that" referred to a narrower scenario than I thought and parent didn't intend any insult.]

</comment></comment></comment></comment><comment><USER7> FreeBSD has a strict rule that each sentence should always begin a new line. The reason isn't so much to simplify editing (not relevant with modern editors) or to make diffs more compact (size hardly matters); rather, the biggest reason is to make "svn blame" work better.

</comment><comment><USER5> This is a topic that has often bothered me when collaborating with people on writing latex.

I use Emacs with auto-fill-mode and Meta-Q to fill paragraphs. This usually works out ok in my own files because usually a re-fill of existing text only affects a few lines.

When other people get involved, diffs and merges are ruined, as the article says.

But the article's solution sounds like a lot of work. Do I have to manually break lines that get longer than 80 characters (or whatever my limit is)? Am I supposed to turn soft word wrap on?

I think the right solution is to rebind Meta-Q in Emacs to some magic command that refuses to reflow any text which is reported as unmodified by the version control, but does reflow new/modified text according to the article's rules, and also imposes an 80-character limit.

Edit [[http://stackoverflow.com/questions/539984/how-do-i-get- emacs...](http://stackoverflow.com/questions/539984/how-do-i-get-emacs-to- fill-sentences-but-not-paragraphs)] has a lot of solutions for getting Emacs to fill according to the article's suggestions.

<comment><USER8> > Do I have to manually break lines that get longer than 80 characters (or > whatever my limit is)? Am I supposed to turn soft word wrap on?

In most situations, there should be _some_ sort of semantic break in your sentences every 80 characters or less. (It may not be demarcated with a comma.) If there isn't, you may want to consider reworking those sentences for clarity.

<comment><USER9> Yes. When writing LaTeX, I put line breaks in after phrases and clauses, as well as at every sentence end. I'm following exactly Kernighan's advice from old nroff documentation.

As a result, my text is very ragged right. I don't even notice it because I'm concentrating on meaning, not form.

</comment></comment></comment><comment><USER10> I love the PWB! [line break] Sometimes the best stuff does not have the best marketing.

Any chance the author can post a copy of the documentation his father had saved for the Documenter's Work Bench?

So many UNIX utilities are line-based, paragraphs just complicate things. [line break] Yet we still type in paragraphs.

You can take the above text and feed it through fmt (one of my favorite utilities) and you get an opening paragraph with two sentences, a single line paragraph, and a final paragraph with two sentences. You can control the line length too. Want 40-column output for better readability? Easy, when using fmt. But you need input that is single lines.

Have you ever ran PDF's through pdftotext or pdftohtml and been frustrated by the formatting? Line breaks from hell.

If documents were distributed in the format the author describes we could convert them into PDF's and other pretty printing formats. But converting from these "paragraphed" formats into readable plain text can be a real nuisance.

</comment><comment><USER3> <http://vanemden.wordpress.com/2009/01/01/ventilated-prose/>

'Ventilated Prose' was a term used by Buckminster Fuller. The blog author linked above is drafting rapidly, then adding line breaks after each sentence/clause as an editing aid. He mentions Vi and the use of dif

[http://lists.canonical.org/pipermail/kragen- discuss/2008-Mar...](http://lists.canonical.org/pipermail/kragen- discuss/2008-March/001086.html)

Found in the comments to the blog post linked above. Just parking these for the inevitable return of this topic.

</comment><comment><USER11> Nice read. Didn't know that this style was documented by bwk.

</comment><comment><USER12> I've been using semantic line breaks for a while for LaTeX since, using Vim, this is the only editing style that is sane on default settings. But that shouldn't necessarily be true; what can I do to make vim friendlier to work with files that are one-paragraph-per-line or similarly formatted? I'm not particularly concerned about version control just editing.

</comment><comment><USER13> I found the incredibly thin page unreadable (had to use Clearly). One sentence per line makes sense for the "source" that you edit, but use something like Latex or Markdown so that we don't have to read it in that form.

</comment><comment><USER14> This clown doesn't even know what a sentence is. In his first example, he has 1/5 sentences per line. Then he changes it to 1/7 sentences per line, i.e. he moves _away_ from his supposed "one sentence per line" target. Yes, in the text of the article he admits that maybe he was thinking about clauses, but I have a zero tolerance policy towards objectively wrong titles.

And of course, the real solution to the problem of "fussing with the lines of each paragraph so that they all end near the right margin" is to use a text editor that soft-wraps lines. Yes, computers have recently become powerful enough to make that possible while editing the document! Amazing.

<comment><USER15> The title is _One sentence per line_ , but he clarifies to include clauses in the body of the article. This also has nothing to do with where the margin ends, but editing text in developer formats that is later transformed to end- user formats in a way that gels well with the tools of the Unix environment. Your comment is unnecessarily venomous and not representative of the contents of the article.

<comment><USER14> Have you noticed how Github helpfully shows which words have changed inside a line when looking at diffs? If we stop teaching people to bend over backwards to accomodate 70s technology, maybe we'll have more young hackers fixing our tools.

<comment><USER15> > Have you noticed how Github helpfully shows which words have changed inside > a line when looking at diffs?

GitHub's web UI only does a line diff. Which is not particularly helpful when you change a word or two in a six sentence paragraph. It's possible to do a word diff locally of course: `git diff --word-diff` but that's not the general use case for a code host, right now most code is line oriented and the UI suits it well. That is one of the reasons that the article advocates formatting thoughts with newlines, good portability. These input texts are closer to code than prose, so why format it like it was? Splitting thoughts into units digestible by your coding environment has the huge benefit of working with individual thoughts instead of individual paragraphs.</comment></comment></comment></comment>