Hook on PG&E Tower Eyed as Cause of Deadly Camp Fire - <AUTHOR> https://www.nbcbayarea.com/news/local/Hook-on-PGE-Tower-Eyed-as-Cause-of-Deadly-Camp-Fire-502035081.html <comment><USER2> I've never understood this urge to find the spark that started a wildfire. The cause of the fire was the large amount of dry vegetation in the area. It doesn't matter what the spark was. If it hadn't been this hook, it would've been something else, such as lightning. Lightning strikes start fires all the time.

Why don't we put more of our efforts into controlled burning in order to keep the fuel load down? Seems like a much safer approach than trying to prevent all fires no matter the cause.

<comment><USER3> > If it hadn't been this hook, it would've been something else, such as > lightning.

Yes and no. While it's true that occasionally there will be natural disasters such as lightning strikes that occur in high-risk areas during times of high winds, power lines are carrying huge amounts of power all the time and thus coincide with high winds more than lightning strikes. As an example of how to mitigate this risk, PG&E has a policy of cutting power to lines temporarily during high-risk times like extreme winds in high risk areas — although in another sign of negligence in this case, they failed to follow that procedure during the windstorm that led to the outbreak of the Camp Fire.

You can't prevent all disasters, but you can mitigate risk, which at least reduces the incidence rate of disasters. It's starting to look like PG&E was negligent in their prevention efforts. I agree that doesn't mean they're entirely to blame, but as a society we still need to hold companies accountable for negligence so that we help incentivize safety.

<comment><USER4> Serious question - how can you hold such companies accountable when fines would be passed directly to consumers? What sane mechanisms exists for this?

<comment><USER5> >Serious question - how can you hold such companies accountable when fines would be passed directly to consumers?

You wipe out the equity holders at a minimum. And possibly break the company up Ma Bell style.

<comment><USER6> > And possibly break the company up Ma Bell style.

So PG&E is split into, let's say, 5 different equal, smaller companies. And Company C caused this fire. Now you have a company 1/5th the size and revenue having to pay the full load. How would that work?

<comment><USER7> Insurance.

This distributes the risk over the companies (useful financially, bad for risk mitigation), but also creates an incentive for the insurer to audit policies, practices, and procedures to minimise risks. Insurance is a pretty powerful business invention, and is unique amongst virtually all businesses in that it _seeks out_ risks (and then tries to manage them).

There are smaller power companies within California (most of them are municipality-owned utilities), and they tend to be fairly accountable to their individual market-owners.

<comment><USER2> Insurance against wildfires doesn't really work. You get one big event and it wipes everything out. It doesn't make any sense for the insurance company to take that bet, unless they're shady and they discharge all of the claims in bankruptcy.

<comment><USER7> State of California says otherwise to the tune of $12 billion.

 _California statewide wildfire insurance claims nearly $12 billion_

 _For Release: January 31, 2018_

LOS ANGELES, Calif. — Insurance Commissioner Dave Jones today announced that insurers have received nearly 45,000 insurance claims totaling more than $11.79 billion in losses from the devastating wildfires that burned across the state in October and December 2017 damaging and destroying more than 32,000 homes, 4,300 businesses, more than 8,200 vehicles, watercraft, farm vehicles, and other equipment....*

[https://www.insurance.ca.gov/0400-news/0100-press- releases/2...](https://www.insurance.ca.gov/0400-news/0100-press- releases/2018/release013-18.cfm)

Again, _insurance companies internalise rather than externalise risks._ They also _manage_ risks.

This can mean changes to construction, landscaping, fire response, utilities operation, activities restrictions (including legal sanctions, e.g., restrictions on mowing or tilling during high-fire season), hydrants, and more.

There are of course limitations to what can be done. A wonderful concept comes from the field of marine navigation and seamanship:

"The Art of ship handling involves the effective use of forces under control to overcome the effect of forces not under control."

\-- Charles H. Cotter

That is the essence of _all_ engineering.

California has extensive experience with major catastrophic fires which have strongly influenced its insurance landscape. The morning of 18 April in 19 and 6 comes to mind.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER8> My two thoughts from the Camp Fire.

1\. Building codes allowed this to happen. Why are people allowed to build homes with asphalt roofs and wood siding in the urban-wildland interface? Indoor fire sprinklers are now required by code, why not outdoor fire sprinklers in interface environments like this?

2\. Could we have an infrared geostationary satellite that could automatically alert fire crews to new infrared events? How about having helicopters on standby ready to respond within minutes of a satellite-sensed infrared flair up?

<comment><USER9> Rooftop sprinklers don't even seem that difficult to install. The house I rent part of has them and they are basically just teed off the same lines that supply the hose bibs on the outside of the house. No risk of freezing pipes over here (SF Bay Area) so its pretty simple.

<comment><USER10> I live on rural property just outside the Bay Area. I can tell you that when there is fire nearby, people do run sprinklers.

Sprinklers aren't magic. They have a very limited range and you must run them for many hours to saturate the area. They might protect you against falling embers but they're not going to slow down a fire jumping tree to tree. And you aren't going to wet down multiple acres of land.

If you're on well (and in the country, everyone is) then you need electricity to run the pumps; did the fire cut you off? Did PG&E, for safety? Very very few solar systems can operate disconnected from the grid. But maybe you have a generator? When was the last time you started it, and do you know how to disconnect the grid and hook it up to the pumps?

Maybe you have a pool and a gas powered pump. When was the last time you ran it? Will it start on the first pull or do you need to rebuild the carb before the fire arrives?

We had a big scare just this last year. We (and everyone else in the neighborhood) ran every sprinkler we had for days. Would it have helped? Maybe, in marginal cases. Mostly it was a good exercise to make us realize how underprepared we really are.

</comment></comment></comment><comment><USER11> Worth noting that in the 2009 Black Saturday bushfires in Australia, there was an AU$494 million class action[0] settlement against a power company (and others), as that fire was determined to have started from power lines.

That said, I'd wait until a proper forensic decision is reached; I can't say I expect a news channel to be too rigorous in its determination of whether a damaged tower caused the fire, or whether the fire damaged the tower.

I also agree with the other comment regarding the need for more controlled/prescribed burning; in Australia again, it is a reasonably established prevention strategy[1], with a long history among indigenous Australians[2].

[0]: [https://www.abc.net.au/news/2014-12-23/judge-approves- black-...](https://www.abc.net.au/news/2014-12-23/judge-approves-black- saturday-class-action-settlement/5984374)

[1]: [https://www.abc.net.au/news/2018-09-13/is-the-prescribed- bur...](https://www.abc.net.au/news/2018-09-13/is-the-prescribed-burn-window- closing-in-australia/10236048)

[2]: [https://landcareaustralia.org.au/project/traditional- aborigi...](https://landcareaustralia.org.au/project/traditional-aboriginal- burning-modern-day-land-management/)

<comment><USER12> Possibly more relevant than the 2009 Australian fires are the 2017 California wildfires from last year in the same area, for which this same utility (PG&E) has liability expected to exceed $2.5 billion[0].

[0] [https://www.sacbee.com/latest- news/article213580349.html](https://www.sacbee.com/latest- news/article213580349.html)

<comment><USER11> Wasn't aware of this, thanks.

Also interesting that three weeks before the Camp Fire began, PG&E were cutting power during high winds.[0]

[0]: [https://www.usatoday.com/story/money/nation- now/2018/10/15/p...](https://www.usatoday.com/story/money/nation- now/2018/10/15/pge-voluntarily-shut-off-power-north-california- wildfires/1646686002/)

</comment></comment></comment><comment><USER13> The tower carried 115 kV and was built in 1919 according to [https://www.chicoer.com/2018/12/07/it-was-originally- built-i...](https://www.chicoer.com/2018/12/07/it-was-originally-built- in-1919-what-failed-on-pge-tower-at-heart-of-camp-fire-probe/)

San Francisco Gas and Electric Company and the California Gas and Electric Corporation merged to form PG&E in 1905.

This technology dates from the almost the earliest days: both Nikola Tesla (d 1943) and Thomas Edison (d 1931) were still alive when this tower was built, and George Westinghouse died only in 1914.

</comment><comment><USER14> The attitude which leads to failure to maintain fits right in with the thousands of D-rated bridges in the U.S. Hey, it's still working and the profits are nice, who needs taxes. Seems laughing at Grandma Millie is still in style.

<comment><USER15> I would think it is a bit different. PG&E is not government and doesn't collect taxes. Those lines originally may have been public property, but I do not know if they still are? I know PG&E talked about burieing them a few years ago after a large fire caused by overloaded transmition lines in North Cali....too expensive. Pretty sure that math Will come out the same way again.

Anyway Gov collects plenty of money for infrastructure projects they would just rather funnel the money into their own pockets via war spending.

</comment></comment><comment><USER16> Much as Californians love to hate on PG&E, and much as PG&E has worked might hard to earn the hate, it's not appropriate to speak of a singular cause of the Camp Fire.

</comment><comment><USER17> Might "Atlas shrug"? Company could respond to liability lawsuits by literally taking down its infrastructure, every line & pole.

<comment><USER18> That would be a boon for solar installers!

</comment></comment><comment><USER19> Warning! Auto playing video ad!

</comment><comment><USER20> yeah as a state we need to limit if not down right outlaw power lines above the ground. Which will be a huge investment and definitely something that PG&E is not going to suggest themselves. But home owners and insurance companies have an interest here. Apart from the 80 people that died, what is the damage in those buildings and loss of economic activity? Much more than putting power lines underground.

</comment><comment><USER21> When the Chicago fire happened, people scapegoated a cow. This feels much the same.

</comment><comment><USER22> Why don't we have a system of aerial drones to monitor this stuff with thermal cameras and be able to respond to incipient fires extremely fast by dispatching aerial firefighting, etc.?

<comment><USER23> Why would an executive at PG&E give two shits about that? They get paid via the shell company that owns the utility and their profits are guaranteed by the public regulator while their liabilities are limited by their corporate structure.

<comment><USER24> I worked at SDG&E shortly after they paid $700M for starting fires in 2007. From my vantage point in the org, I saw that (a) the executives felt pressured, (b) much of the cost was borne by shareholders not ratepayers, and (c) this incentivized the company to invest more proactively in fire prevention strategies.

Sources:

-CPUC rejects SDG&E's attempt to pass on costs: [https://www.sandiegouniontribune.com/business/energy-green/s...](https://www.sandiegouniontribune.com/business/energy-green/sd-fi-sempra-earnings-20171030-story.html)

-Sempra (the parent company) settles for $700M in damages: [https://uk.reuters.com/article/sempra/update-1-san-diego-uti...](https://uk.reuters.com/article/sempra/update-1-san-diego-utility-to-pay-700-mln-in-fire-claims-idUKN2635565720090627)

-Sempra's earnings and shares down as a result: [https://www.sandiegouniontribune.com/sdut-sempras-1st-quarte...](https://www.sandiegouniontribune.com/sdut-sempras-1st-quarter-marred-settlement-weak-earning-2010may04-story.html)</comment></comment></comment>


Show HN: A script to move links on HN to undesirable sites to the bottom - <AUTHOR> https://github.com/vishaldpatel/HNLinkMover <comment><USER2> I would retitle this to "A script to move links on HN to paywalled sites to the bottom"

I would also suggest maybe just highlighting them in some way, because while for you the paywall might be undesirable, to paying subscribers, or even curious readers who just want to peruse the comments, it would be nice to know the site is paywalled first, but still that it is a high ranking item.</comment>


FAA can't oversee most airline maintenance, since it's done outside the USA - <AUTHOR> https://www.vanityfair.com/news/2015/11/airplane-maintenance-disturbing-truth?verso=true <comment><USER2> Two people well known to me who both spent their careers in aircraft maintenance told me after the Ethiopian crash that nearly all airlines, including US carriers, buy fake parts -- ones that are not approved by the original manufacturer.

Obviously, I can't cite a source, but I wonder how long before _that_ scandal hits the news.</comment>


Who's building Linux in 2017? - <AUTHOR> http://www.zdnet.com/article/whos-building-linux-in-2017/ <comment><USER2> I develop on a linux desktop, my code runs on a linux cluster. My phone runs on a linux kernel. The only time I leave is when I want to play a game. I could get rid of Windows altogether if steam and the VR games I play started to run in linux.

</comment><comment><USER3> Quite amazing to have so many contributors working at such a rate (204 patches a day!) on a Free Software project.</comment>


Smarter half tiling in Gnome Shell/Mutter - <AUTHOR> https://feaneron.com/2017/06/13/smarter-half-tiling-in-gnome-shellmutter/ <comment><USER2> The news is, that it finally landed!

[https://feaneron.com/2017/10/03/improved-half-tiling- availab...](https://feaneron.com/2017/10/03/improved-half-tiling-available-in- mutter-3-26-1/)

</comment><comment><USER3> Are we reinventing tiling window managers?

Because if we do, that's awesome! DWM is by far my favorite wm and would give anything to have similar functionality in other WM and maybe Mac and Windows.

<comment><USER4> Windows already has the feature covered in the blog post (in 10 it supports quarters).

There are also a number of third party tiling window managers.

</comment></comment><comment><USER5> I've been waiting for ages for better tiling in Gnome - at least something like Windows 7 does would be great (resizing after half-tiling), but this looks even better! :)

</comment><comment><USER6> I'm so ready to jump from my i3 setup to Gnome if they get the tiling even half as good as i3's is. Why? Because of Wayland (which gives me proper (Hi)DPI support for multiple monitors) and integration that I don't have to tweak myself in order to work.

So quite excited about this.

<comment><USER7> Somewhat related:

Regarding i3-wm is there such a thing as pre-defined resolution tiling for the sake of UI testing? That would be pretty neat.

Imagine a bunch of windows that were tiled (think mosaic) according to known device resolutions like 320x680 (or something like that for mobile devices) then you could have say a browser open in each tile (with local dev url) and refresh/shows the UI as displayed on every resolution that would be impressive.

<comment><USER8> You can poke the i3 API to resize windows, but for arbitrary resolutions you need floating windows and that defeats the point of i3.

<comment><USER7> What is the point of i3?

I use it because the Ubuntu UI uses so much resources (from my experience) and my computers are generally trash.

<comment><USER8> IMHO, the point of i3 is having tiled windows. As a stacking window manager it's quite bad because it has no compositor.

That's why it's fast, but badly coded applications can be less stable.

<comment><USER7> Interesting, I don't know what Compositor is but agree with the speed.

</comment></comment></comment></comment></comment></comment><comment><USER9> Does anyone else who does even basic half-and-half tiling feel like the majority of websites, even otherwise well-developed and popular ones, treat tilers as second-class citizens? I'm looking at you, GitHub, especially the ZenHub plugin. For a great counterexample of great design, YouTube.

</comment><comment><USER10> Always a little confused by what 'tiling' is. On gnome I use 'untiled'/overlapping windows, and with SYS-right/left/up/down, ALT-tab, ALT-`, ALT-ESC, etc. shift windows around on gnome. That's it, plus quarter- tiling and definable keyboard combinations?

What would be really useful is a workspace organizer that given a keyboard combination automatically opened a number of applications in preset locations (on a new workspace); i.e. set up a work environment for a specific task. Is that possible with a tiling manager?

<comment><USER11> StumpWM definitely has the ability to open a number of applications in preset locations, they call it 'Groups'. I'm sure it isn't a novel feature and you'll find the same ability in a more common, less Lispy tiling window manager like Ratpoison, i3, or Awesome.

</comment></comment><comment><USER12> GNOME 3.26 will be in Fedora 27.

The beta is out: [https://fedoramagazine.org/fedora-27-beta- released/](https://fedoramagazine.org/fedora-27-beta-released/)

</comment><comment><USER13> I love mutter. It's been ages since I looked at it, but at the time it looked very difficult to pull out of Gnome (which I don't love _). I really should look at it again.

_ I should clarify that I actually like Gnome Shell, but I don't want a "desktop environment" \-- I like a minimal system and Gnome is well past what I would ideally like.

<comment><USER14> It's pretty straightforward to use mutter without gnome-shell, you just have to implement the MetaPluginClass [1], which is what gnome-shell does too here [2]. At that point you can basically just run `meta_init()` and `meta_run()` in main and you're up and going.

[1] Somewhat outdated documentation: [https://developer.gnome.org/meta/stable/MetaPlugin.html#Meta...](https://developer.gnome.org/meta/stable/MetaPlugin.html#MetaPluginClass)

[2] [https://github.com/GNOME/gnome- shell/blob/master/src/gnome-s...](https://github.com/GNOME/gnome- shell/blob/master/src/gnome-shell-plugin.c)

<comment><USER13> Thank you! I appreciate it.

</comment></comment></comment><comment><USER15> Finally! Now, if they could allow horizontal splits on rotated screens... because who wants two 600x1920 windows.

</comment><comment><USER16> The drag and drop resizing reminds me of [https://bluetile.org](https://bluetile.org) although that seems to be more powerful (arbitrary layouts, rather than just side by side).

For the record I use Xmonad on Xorg, with no DE and little mouse usage :)

<comment><USER17> I am slowly preparing to depart my lovely xmonad setup for gnome due to issues with HiDPI..., but I still love the multi-screen support in xmonad.

</comment></comment><comment><USER18> Does it work sensibly if I'd like to do a 3-part split too?

</comment><comment><USER18> An interesting related idea which was prototyped and merged into Haiku OS some years ago:

video: [https://youtu.be/ccniJHjo_Uw?t=124](https://youtu.be/ccniJHjo_Uw?t=124)

user guide: [https://www.haiku- os.org/docs/userguide/en/gui.html](https://www.haiku- os.org/docs/userguide/en/gui.html)

</comment><comment><USER19> If this piques your interest, you might want to give shellshape a look as well. [https://extensions.gnome.org/extension/294/shellshape/](https://extensions.gnome.org/extension/294/shellshape/) . It lets you tile your windows in a more advanced way than simply side by side.

<comment><USER20> Has Shellscape fixed the bug with size-hinted windows?

I found that when you had two terminal with size-hinting tiled, and the 'wrong' window resized, shellscape would wig out and pit the size-hints of both windows against each other, resulting in windows resting in some weird geometry and position.

</comment></comment><comment><USER21> One more feature request: Hitting Win-Right twice on the left monitor should move the window to the left tile of the right monitor.

<comment><USER22> I am using Gnome Shell 3.24.3 but I think this has been available for quite some time. If you hold Shift+Win and then use the arrow keys to the left/right you can move the window between the screens.

<comment><USER21> Yes, but why do I have to use a different key combination for moving windows between screens than for moving them within the screen? Besides, this moves the window to the same position on the other screen, as it currently is on the current screen.

It would be much more useful, and indeed the default in Windows and the several macOS implementations, to move the Window to the "next available tiling position" in the indicated direction. Thus, consecutive Win-Right should move the window to

\- the right half of the left screen \- the left half of the right screen \- the right half of the right screen

<comment><USER23> In Gnome 3, I think the workspaces are arranged vertically by default. Win+Right makes me think of the workspace to the right, but the next workspace would be below.

</comment></comment></comment></comment><comment><USER24> I'm still stuck with Shelltile until quarter-tiling arrives (gotta have a browser, terminal, and editor window for maximal happiness). But, it sounds like it's coming, so that's awesome!

</comment><comment><USER25> Nice feature. If you want more you can use a tiling windows manager in top of gnome.

<comment><USER2> Unfortunately that is not that easy anymore. There are extensions that can tile more sophisticated though.</comment></comment>


Memory management in C programs - <AUTHOR> http://nethack4.org/blog/memory.html <comment><USER2> Jesus Christ. Let the reader beware indeed. There are horrible suggestions here that will result in bad code if you think "Hey, that's a cool suggestion, I'll try that!". Or "Hey, I read in that blogpost this is OK in C, I'll do this".

For instance: Stack allocation. It's seldom OK to use static variables even with accessor functions. Wrap the state that the functions operate in structs that you pass to functions. There are a few places where you cannot avoid effectively global variables (usually external resources like sockets, window handles etc) but those should be wrapped in their own subsystems and not leaked all around the place in global variables. "Still, this is one of the better reasons to use a global variable." \- congratulations, you are on your way to Spaghetti Code land. Would you like some black pepper with your Complexity Bolognese? Protip: Wrap it in a struct and pass it as a variable. Or redesign your module dependencies.

Too much state in your God-Object. Getting confused? Need better design. C is not an excuse not to write modular, understandable code where the program flow is obvious.

Yes, it can get really verbose. If verbosity is an objection, then do not write in C.

Or, if you dislike verbosity, do what so many others have done. Write your core routines in C and then write the high level logic in Lua.

Please excuse me my theatricality. I'm not assaulting the author. I'm rather agravated that this post has this level of visibility and the potential damage it can do.

<comment><USER3> > Please excuse me my theatricality. I'm not assaulting the author. I'm rather > agravated that this post has this level of visibility and the potential > damage it can do.

I thought it was a good post and provides a good overview of different methods along with a discussion why you should or shouldn't do some of these things.

I'm pretty certain that in the Linux kernel you can find each and every one of these methods used more than once and for a good reason.

Maybe in a normal user space app you have the luxury of being able to malloc/free everything and have nice high level containers, etc available but when writing C code, the assumption of normal user space apps is not necessarily true.

All of these methods - and when _not_ to use them - is very useful knowledge.

<comment><USER4> It's amazing how much you can achieve without malloc and free if you're just careful to pass in the right output space and buffers as part of your function call. You rarely really need them for most functional code. (Non-trivial data structures may be different...)

And the OP is right - globals, especially if not encapsulated within a single code module, are a prime cause of opaque spaghetti code.

<comment><USER5> I've written plenty of embedded code where the first rule was "Thou shall not malloc." In just about every case it turns into setting aside static buffers and doing manual structure allocation. This is such a common idiom in embedded systems that most RTOS systems have this functionality built-in.

<comment><USER4> The embedded system I'm working right now doesn't have malloc as part of its platform SDK anyway, so it's not like there's a choice :)

I guess it depends on what exactly you're working on, but passing in a stack- declared for a function to fill with its results seems better to me anyway, as general practice. Preferable to allocating a new structure in the function and then returning it, that is. There are no ownership issues and nobody has to remember to free anything.

Heap emulation with static buffers comes with its own costs - either you end up writing an allocation engine or you just use a large buffer with an advancing pointer, free() does nothing and the whole thing has to be reset every so often, which means that you have to convince the other developers on the team that it's _not_ to be used like normal malloc and please be careful and ... that's a whole other can of worms!

</comment></comment></comment></comment></comment><comment><USER6> _"...converting NetHack's codebase to a new language would be very difficult (even one as similar as C++, which has many potentially relevant details that differ from C)."_

I was a NetHack devteam member for a few years in the late 1980s and early 1990s, so I got to know the code pretty well... it's pretty hairy, and that may be putting it mildly.

I wish the NetHack 4 folks would reconsider and explore a complete reimplementation in a new language. Yes, it would be a much more significant project, but I think it would be the best thing for the game in the long run. And it would be a lot of fun, but I'm biased.

I wonder what language would be the best choice at this point, for such a project.

<comment><USER7> I'm another NetHack fork developer (with UnNetHack leading a small team and with NetHack-De having a fun side project), so I also had to think about the issue of rewriting in a new language.

But this is just a huge undertaking for very little gain. You rewrite the 110K LOC of the core game engine in a new language so it works the same as before (which will be difficult because no tests) for having ... what exactly?

If you don't have years to spare, an incremental rewrite would be a viable option. But do Objective-C or C++ really look like a good choice nowadays?

Then there's also some big non-technical issue. With a rewrite in a different language you lose the connection to the old code that dates back to the 80s. It would no longer be a NetHack fork but a NetHack clone. For a fork developer who already has to fight an uphill battle as the DevTeam is dormant for 10 years but is still claiming that they are working on $NEXT_VERSION, this would be another of those arguments for "it's not the real thing, I'd rather play vanilla".

BTW, for a reimagination of NetHack that did something similar, take a look at [http://www.wazhack.com/](http://www.wazhack.com/) . They weren't that exactly replicate the NetHack functionality but it at least _feels_ close.

 _I was a NetHack DevTeam member for a few years in the late 1980s and early 1990s, so I got to know the code pretty well... it 's pretty hairy, and that may be putting it mildly._

For the time it was written in and with the organizational structure it was developed with, I think it's surprisingly good. After all, it is still C, so it is not for the faint of heart anyway. Sure, there are things that could be better, like that monster attacking monster, monster attacking player or player attacking monster is usually coded in three different places. But for a code base of this size, it's overall not bad. I find myself cursing more often about the limitations of C than of NetHack's code itself. :)

 _I wonder what language would be the best choice at this point, for such a project._

Depending on what your goals are, C could still be the best choice for such a project.

If you want a program that runs on as many different systems as NetHack does, C is still hard to beat. Heck, it even works on Android and iOS.

Maybe something like Rust or Go, but we're still not there that C has been clearly superseded in all domains.

<comment><USER8> > If you don't have years to spare, an incremental rewrite would be a viable > option. But do Objective-C or C++ really look like a good choice nowadays?

Anything that compiles to native modules and has a clean C FFI would work. You could encapsulate the current code into a black-box set of APIs, and then transition those APIs module-by-module from being calls into the old crufty code, to being calls into shiny new rewritten code. (This is the strategy recommended at [http://laputan.org/mud/](http://laputan.org/mud/)).

Go is pretty perfect for your use-case, though; it produces portable, low-ish level application code, and while it's a bit less performant than C, you don't really need every scrap of C's performance in the way an OS or a 3D game does. Besides all that, it's very easy for grumpy, staid old C developers to learn, in the same way that Plan9 is easy for grumpy, staid old Unix administrators to learn: it's all the same ideas, just streamlined for newer use-cases.

<comment><USER9> I don't think Go is the right option here, while you can call C code from Go, last time I checked it wasn't possible to call Go from C without having it called the other way around before. I'd rather suggest going for C++ (or maaybe Rust... well, not really).

<comment><USER10> The language may not be mature yet, but C code can very easily call into Rust code (and, by proxy, any language that can call into C can call Rust code).

</comment></comment></comment></comment></comment><comment><USER11> Memory management in C is really not that hard. If it's big, use malloc or calloc. If it's small and of fixed size, use the stack. Don't use globals unless you really, really have a good reason.

Yes, you can get leaks with malloc. But valgrind is actually really good at finding them. So if you have reasonable unit tests, you can just run valgrind on all of them and get a lot of coverage.

The problems that Nethack is having are basically self-inflicted. They opted to use setjmp and longjmp to emulate exceptions. So they don't have a good way of cleaning up things they malloc'ed. setjmp and longjmp are basically a way of implementing a cross-function "goto". it's just as bad as it sounds. Not to mention, they use a lot of functions like sprintf that have basically been banned by everyone else in the world. Hopefully they're not using gets()...

You don't need to implement crazygonuts memory management unless you're writing a high-performance database or kernel or something. Certainly not for a text adventure! Just. Use. Malloc. So this whole thing is just an exercise in making something really simple into something really complicated. Which I guess is what Nethack is, anyway.

<comment><USER12> Allocating chunks over ~1024B repeatedly becomes really slow, because malloc tries to return as much memory back to the system when you free. This takes magnitudes more time than just a function call. There are some parameters you can tweak in it, but I think that is the reason many games have their custom allocator, which malloc a huge chunk of memory and then keep it until the program exists.

<comment><USER11> Some malloc() implementations return memory to the OS during free(). Many don't. For example, tcmalloc in its default configuration never returns memory to the OS.

Also, what is "really slow" in the context of nethack? I'm willing to bet that you could malloc and free till the cows come home and never even notice in nethack. I bet the whole program doesn't take up more than a few megs of memory anyway.

</comment></comment></comment><comment><USER13> Most of these techniques are extremely commonplace in embedded C programs where you might have a combination of the following: no malloc/free, no operating system or threading library (everything sits in a void main() { while (1) {} } loop, you have limited memory and you need to fix the size of your data structures, you need to reason about the correctness of your code for safety/security purposes and not doing any dynamic allocation makes this a lot easier.

I've had to code on embedded devices (where RAM is anything from 4kb to 512kb) where all the above have been true at some point.

<comment><USER14> I've been working on Storage systems with multi-gigabytes of RAM where you still reason about your memory in much the same way. These systems have lots of RAM but properly intend to make use of all of it.

I tend to prefer to allocate on the stack when possible and when the context is right and that works when working in threads or user-space-threads (aka coroutines) that are all hierarchical. It makes some things simpler though you need to care about the stack size and its usage. The places that do need dynamic memory allocations would normally use a memory pool for same sized objects to be allocated from.

</comment></comment><comment><USER15> Nearly all the time, memory management in C can be done using the following incredibly sophisticated pattern: create an object at the start of a function, and destroy it at the end of the same function. Use constructor/destructor functions or macros to hide the details (such as whether the object is a plain fixed-size struct, or has to allocate additional variable-size memory on the heap). There are situations where this pattern cannot be used, but they can be made very rare in properly structured C code.

Finally, write unit tests and run them through Valgrind. That catches almost all memory-related bugs.

<comment><USER16> I can see where you're going with this, but I think you're being a little glib with the "nearly all the time" bit. There are large chunks of functionality that can't be written that way. The most obvious one is graphical objects, which are typically expensive to render. You can't be destroying / recreating them on the fly, the number of graphical elements in use changes radically over the lifetime of a typical graphical application, and you generally have an event loop, which means the only function that would keep the objects alive is at the top level of the event loop.

I personally tend to look at malloc/free in the same way that I look at if statements. I generally consider code to be cleaner without them, so where possible I will avoid them, but sometimes that's not possible, which is why malloc / free (or if statements) exist.

<comment><USER15> Yeah, definitely a little glib. There are certainly prominent exceptions. Still, I think it's a valid general principle. At least, it works well enough for me, and I very rarely have to think consciously about memory management in C. But YMMV, different application domains, and all that.

</comment></comment></comment><comment><USER17> In consoles games, often the following is found - big double-stack - predefined buffer, that takes most of the memory. Memory is allocated by bumping a pointer, for example data for levels loaded increases left -> right (up->down), and temporary data (characters, temp scene, etc.) right->left (down->up). When level unloads (or several of it's associated files), memory is put back before (left or right).

But there are always other heaps (that might or might not work like the stack above, or have say dmalloc's mspace api used there for other uses), and some space should be left to CRT itself, nowadays even more with lambda's in C++11 and for other library functions.

For Tools I started to not care, simply because it does not matter that much. Just make sure _NO_DEBUG_HEAP=1 is set when you run through the Visual Studio debugger :)

</comment><comment><USER18> > but if there are no normal returns involved, nothing on the stack will ever > be deallocated, and your program is effectively just one giant memory leak.

This is true, but there is the glorious exception which is "Cheney on the MTA": [http://www.pipeline.com/~hbaker1/CheneyMTA.html](http://www.pipeline.com/~hbaker1/CheneyMTA.html) [[https://news.ycombinator.com/item?id=7417906](https://news.ycombinator.com/item?id=7417906)]

This describes a way of implementing a scheme->C compiler using CPS which allows the C functions to never return, and doesn't blow the stack. When the stack gets big enough, you do a garbage collection run, copying live data to a new stack. Then, you reset the stack pointer using a judiciously chosen argument to alloca().

</comment><comment><USER19> Detailed articles like this are great for understanding and exposing all the _freedom_ and _power_ you get with C's memory management philosophy. I agree with the author's view that it is sufficiently complex that it can force you to think about _not_ allocating, i.e. "should I really be doing this?" and thus you often arrive at a simpler, more efficient solution than you would if you'd used something like Java and thought "I'll just create a new X object". I see this all the time in C code written by programmers who first learnt Java - malloc()'ing and copying objects everywhere, often with an underuse of free() and thus plenty of memory leaks.

My personal preference is for not using fixed-length buffers for storing things like (non-static) strings, unless I know for certain that they won't _ever_ grow past a certain length (and document it clearly, so if something ever needs a length check I can go back and find them); strings of user input and other possibly indeterminately long things get documented as "limited by available memory" (i.e. they're dynamically allocated) or "limited to X bytes" (usually due to a fixed-length buffer somewhere).

As a note, the fragment

        str = malloc(1 + sizeof "submenu");
        strcpy(str, "submenu");
        return str;

could be replaced by a single

        return strdup("submenu");

<comment><USER20> 1) that will call strlen on "submenu"

2) the writer may be using a different malloc than the libc one

3) there is an argument to be made that using malloc plainly like this instead of hiding it with strdup makes it easy to see the sites in your program where heap memory is allocated

<comment><USER21> 4) `strdup` is a POSIX extension whereas NetHack is cross platform.

<comment><USER22> Easy to fix with a macro.

</comment></comment></comment></comment><comment><USER23> I wish these kind of articles targeted to higher-level programmers would start teaching to use 'calloc' before 'malloc'. New C users will have a bad time catching random bugs when they allocate a struct via malloc and immediately check members using de-referencing in 'if' conditions which will be randomly evaluated as true because malloc doesn't initialize the memory to zero and therefore all the members of the struct through the pointer returned by malloc are full of garbage. My rules are: either use malloc if you intent to immediately initialize the memory or use calloc and pass the pointer around.

<comment><USER4> IIRC while this is true and good practice, many modern OS/libc implementations will zero stuff anyway.

<comment><USER24> Don't count on it.

Modern OSes will zero out pages when your process brk()/ mmap()/etc. them into your address space, to avoid security problems. However, unless you're using a debugging version of libc/LD_PRELOAD'ing malloc/free implementations, etc., I don't believe most malloc/free implementations will necessarily hand you memory containing a known pattern. Certainly the main selling point of non- default malloc/free implementations is performance. Zeroing out memory between uses by the same process has some overhead, and the benefits are more of a mixed bag than the case of accidentally leaking sensitive data a programmer has forgotten to zero out (or doesn't think is sensitive) between processes.

Your free() implementation can't return partial pages[0], and in general will only return multi-page contiguous blocks to the OS, due to memory fragmentation, anticipation of soon needing to malloc() again, and a desire to keep system call overhead down. The consequence is that if you do a lot of malloc()ing and free()ing, you're likely to sometimes get zero'd out pages, and sometimes get garbage that your process has previously written to memory, but you should never get garbage that another process has written to memory. (Unless, of course, it's shared memory or copy-on-write shared with a parent process.)

[0] Well, if your CPU/MMU supports segment registers or you're willing to do unsafe things that can't be enforced by the MMU, then your OS could support returning partial pages to the OS. However, modern desktop/tablet/smartphone OSes don't work this way.

EDIT: Too lazy to read how to get asterisks to show up consistently. I changed *aloc to "malloc".

</comment></comment></comment><comment><USER25> Techniques like these are always interesting, even if you don't have much opportunity/need to apply them. The source for software like NetHack might not be a good place to look for best practices, but it can be enlightening in other ways (if you're careful to avoid copying just anything you see).

On that note, while the article doesn't (explicitly) mention it, it would be wise to remember that VLAs of unbounded size _will_ end up overflowing the stack eventually. They have their uses, but can be tricky to apply safely. Be careful!

</comment><comment><USER26> Re stack allocation: _It requires you to know how large the object could possibly be at compile time_

Just wanted to point out that alloca exists pretty much everywhere, so you don't need to know the exact size at compile time. You still need to know you're not going to overflow your stack, of course.

There are also variable-sized stack allocated arrays, as in C99 and gcc extension.

Though IMO the value of a consistent approach outweighs the small performance advantages of dynamic stack allocation - it would very very rare for me to use either approach today.

</comment><comment><USER27> I've worked on embedded C++ network stacks that restrict use of *alloc and new for various sized buffers and classes that have to be preallocated. That's one approach.

Just wondering why tcmalloc or boheme GC weren't discussed. Rewriting from scratch often equivocates to reinventing wheels, and avoidable typing, testing and maintenance. --effort && ++quality == awesome;

</comment><comment><USER28> RAII and smart pointers pretty much make C, and the programming style typical of C programs, obsolete.

C will always be here for historical reasons and because of all the code written in it that would be difficult to convert. But new development should be in C++. Yes, Linus, if you were starting Linux today I'd take you to task for not using C++. :)

</comment><comment><USER29> There is malloc and free.

Anything you do above that to make your life easier is up to you.

C is pretty darn simple in terms of memory management -- you own it, deal with it. If that is too hard, find a higher level language.

<comment><USER30> What's your point exactly?

<comment><USER29> I welcome the down votes.

My point - I read the article and agree as described are typical ways of dealing with memory in C (and in particular within Nethack). At the end of the day, dynamic memory allocation comes down to tracking mallocs and frees and whatever extra book keeping you put on top of them.

Reference counting came up. There are libraries that help with such, but you better understand what that actually means.

Wrapping primitives in higher level abstractions can lead many developers to wondering why there is a memory leak. Before you embrace the abstractions, you better darn well understand what is going on under the hood.

I've seen many inexperienced devs get lost in simple valgrind dumps.

<comment><USER31> You're being downvoted because these comments have little to do with the content of the article, which is about "dirty" low-level memory management techniques designed to avoid naive heap allocation, not trying to abstract the problem away.

</comment></comment></comment></comment><comment><USER32> On a somewhat related tangent, but a tangent just the same, Ada came to my mind because people in another thread about avionics in relation to the Malaysia Air Flight were debating the efficacy and/or safety of Ada versus a language like, for example, Haskell.

When I looked into Ada and memory management, out of curiosity, I did not find a lot of information about pointers. Or a garbage collection system, and casual reading confirms that Ada has a less manual version of pointers (from what I gather) and manual memory management, and no garbage collection. Given its syntax and semantics, which remind me very, very vaguely of Haskell (which I am sure is bound to insult someone on HN, specifically Haskellers), I could not imagine this as a systems language. Then again, even though I am ignorant of such things and do not know C/C++ (the latter I only took briefly in undergrad, and I have mixed reactions), I am product of the C/C++ generations and the stand of the shoulders of Unix and Linux giants, as I have looked into computer science and Linux application source code in attempt to understand. Not even write the code mind you, just understand. Perhaps others were exposed to Pascal and BLISS, so the alternative perspectives made it seem possible. I do not have that perspective, so I feel dazed and confused by alternative offerings when reading them. I get the idea generally, but still whisper to myself with a concerned "How!?", even though it should be more obvious.

In short, I cannot really conceive of manual memory management without pointers and pointer arithmetic as it presented in C and/or C++. I was terrible at it, granted, but everything else I see from Rust to other system languages which promise a systems language without GC and offer some equivalent of memory management done manually do not click. They seem foreign and impossible because I have always assumed, for better or worse, C is the way you interface with a modern PC or embedded system by managing each and every pointer, or you are on your way to assembly and then memory is one of many complicated underpinnings you must understand intimately, not just the must troublesome one.

But I am an amateur programmer. I recently the saw the threads on FORTH. I want to look because, as much as I "know computers" the idea of this kind of very low level stack language is very foreign to me, just from looking at it I feel odd and not sure how it could possibly work. The same would be true of writing low level code in Haskell. I like it a lot, for all its beauty and warts, but I have just assumed you must learn to manage such things manually and in an ugly fashion a la C/C++ to learn system management in a programming language in our generation, and no amount of screaming or holding your breath until in the red face will change that.

However, a lot of this is conditioning. Maybe others can share other observations to counter my admittedly very naive experience.

<comment><USER33> > Ada and memory management

Ada does not specify GC. Ada does have pointers; it calls them "access types". It supports unconstrained types, which are allocated on the stack when declared (no need for malloc/new). It also supports more sophisticated memory management abstractions, like Storage Pools and Controlled Types.

> I could not imagine this as a systems language.

Ada was designed to be a systems language, provides all the facilities one would need, and is extensively used as one. So beyond "it's not C" I don't really know how you could come to that conclusion.

<comment><USER32> I saw that access type information, but the docs were not clear to me.

What you question is the central point of my comment: maybe I am biased by learning C++ on SunOS, then playing with Linux, then using FreeBSD at work, but it is hard for me to imagine systems programming without C/C++-colored glasses in terms of memory.

I have no doubt it is possible in Ada. It is just less ugly and dangerous than C, so I thought you are just forced to deal with pointer management in your own brain with rough syntactic constraints because that is the highest you can go wo systems programming on the metal without going to assembly.

I know it seems silly, but that I think drives people to embrace C completely as the only answer, and not just the preferred answer. Fortunately, forcing many to deal mean there has been good progress since the OP article was first published.

<comment><USER33> I think you're using an awful lot of words to say "if all you have is a hammer, then every problem looks like a nail". Yes, if all you've ever been exposed to is C/C++/Unix like environments, then an idiomatic Ada solution to many programming problems will be conceptually difficult to grasp. That would be true of any not-C/C++ language or not-Unix environment.

<comment><USER32> Sorry, I am wordy because I was busy and overtired. To keep it brief: you seem to have some knowledge on Ada, can you point me to any interesting open source projects I can use to understand? I have tried and not found many.

<comment><USER33> I don't have any particular suggestions for open source Ada projects to examine (other than, obviously, the GNAT Ada compiler). My experience with Ada was on decidedly not open source projects, and Ada suffered in this respect in that there wasn't a good open source Ada compiler until long after interest in Ada outside of the defense industry faded. Googling for "ada open source" shows a good number of interesting (if dated) possibilities (these might be a good place to start: [http://www.pegasoft.ca/resources/boblap/book.html](http://www.pegasoft.ca/resources/boblap/book.html) and [http://www.seas.gwu.edu/~mfeldman/ada-project- summary.html](http://www.seas.gwu.edu/~mfeldman/ada-project-summary.html)), but not to put to fine a point on it, the cool kids pretty much decided Ada was the US DoD equivalent of COBOL 20 years ago and ignored it.

As an aside, Ada was intended for large numbers of programmers of varying, often mediocre skill to cooperate on large programs while minimizing errors and preventing localized programming errors from propagating too far. That's something a lot of OSS projects could use.

I also think it's important to understand that Ada was one branch of a family of languages descended from ALGOL that looked at the problem through a similar lens (a very not-C/C++ lens). Pascal is the direct ancestor, of course, but in a addition to Ada, Pascal evolved into a number of other systems programming languages like Modula-2 & -3 and the various Oberons. Close cousins Mesa & Cedar were Xerox PARC systems programming languages. There's not a lot left of the Modula's or Mesa/Cedar (regrettably...Modula-2 was much better than Pascal for non-academic programming and Modula-3 was a really comfortable all-around language), but there's a reasonable amount of OSS Oberon laying about.

EDIT: How could I forget...if systems programming is your kink, be sure to check out UCSD p-code and ETH m-code. These are Pascal/Modula virtual machine environments and the direct ancestor of the Java VM and M$ CLR.

<comment><USER32> And with Ada that is the problem: not much out there. I did see some people using it for Arduino, I thought that was neat and why it came to my interest again.

As for Pascal and Oberon, when I saw the computer and OS of the same name written in Oberon (I think), my mind was blown with how advanced it was. Thanks for the good comment.</comment></comment></comment></comment></comment></comment></comment>


Magicka Wizards of the Square Tablet out now on iOS, Android - <AUTHOR> http://www.joystiq.com/2013/03/30/psa-magicka-wizards-of-the-square-tablet-out-now-on-ios-androi/

<comment><USER2> I hope Android turns out to be a profitable platform for Paradox Interactive. Paradox is known for pushing creative game ideas and is not afraid of niche markets (like historic politic simulators). They have earned a lot of credibility in the PC market, both as a publisher and a developer.

Its good to see that they now look beyond windows, and most of their own games are perfect for touch based devices.</comment>


California "Kill Switch" Bill Could Be Used to Disrupt Protests - <AUTHOR> https://cdt.org/blog/california-kill-switch-bill-could-be-used-to-disrupt-protests/ <comment><USER2> Hi all; original author of this blog post, happy to see it getting so much feedback. I think it's important to highlight the risks in and out of state:

The bill says that police CAN use this mandatory kill switch, but must comply with Public Utility Code Section 7908 in doing so; that law generally requires police to get a warrant before shutting down cell service, but has an "emergency" exception where court approval is not required. I worry police could abuse this, using risk of violence as a pretense to shut down a protest as CA police did during the BART subway shutdown in 2011.

A more broad risk is that because CA is such a large market, manufacturers/providers will likely deploy this mandatory kill switch nationally, so it could end up being used in other states (such as during protests in Ferguson, Missouri)that may have absolutely no restrictions on government use of a kill switch.

Unfortunately the bill is very far along so there is not much left that can be done, but I would recommend discussing the issue on social media, and, as @javajosh suggests, contacting Governor Brown's office to express concerns and recommend a veto. The bill was passed on August 12 so he must sign or veto it by August 24.

<comment><USER3> Yes, the bill has an emergency exception, but you omitted to mention that it _still_ requires police to go to court afterwards (within 6 hours, or with additional submissions to justify the delay if that is not possible) to make a showing of why a communications interruption was necessary, and requires the court to balance police claims with First Amendment freedoms, strictly limiting the scope of acceptable reasons and requiring the purpose of the interruption be as narrowly tailored as possibly.

I don't understand why you left all this out of the original story.

<comment><USER2> Because prior judicial approval is the key check to preventing government abuse; if police want to shut down a protest a judge potentially telling them they went too far 6 hours later is not going to help.

<comment><USER3> And they're supposed to get prior judicial approval. It's only acceptable to file retroactively in cases where there is an _imminent_ risk of death or great bodily harm, such as a hostage or barricade situation or other 'extreme emergency situation.'

You're assuming the worst possible outcome (police overreach, court apathy) and using that as a justification to omit any mention of the copious rules limiting official use of this power. I find it rather ironic that you decided to leave your readers poorly informed about this, not least because it would put them at a disadvantage in any argument with a supporter of the bill.

<comment><USER4> The problem is that "imminent risk" tends to creep downward over time, to the point that it becomes "imminent risk that a citizen unit will improperly fail to bow and scrape."

If you're going to shut off several thousand cell phones, you can bloody well get a judge out of bed for that.

<comment><USER3> Perhaps, but I don't think it's fair to judge this bill on how legislators might amend it in future, or we'll never pass any laws at all.

<comment><USER5> Laws have unintended consequences. It's good to slow down the creation of laws and weigh tradeoffs. Laws are intended to be solutions. But the cure may prove worse than the disease.

</comment></comment></comment></comment></comment></comment></comment><comment><USER6> There are fundamental freedoms the government cannot and should not be able to subvert. Communicating with others, via any means necessary is one of them.

I feel I am politically very far away from many guns rights activists, and am wary of the practical outcomes of widespread weapon ownership, but at the same time I believe 2nd Amendment advocates are completely right to be wary of government's ability to strip individual power to protect and disrupt.

<comment><USER7> If this legislation passes (and I hope it doesn't) there will be an immediate First Amendment challenge.

One place where we've been lucky is the fact that the FCC has rules against jamming of any sort of radio signal.

<comment><USER8> This isn't jamming a radio signal, it's disabling a device which has a radio in it. There's no FCC issue here.

<comment><USER7> I know. My point was that that regulation protected us in absence of having a kill switch on phones.

</comment></comment></comment></comment><comment><USER9> Here are things we know, and that we have known since the "kill switch" was first proposed:

1\. Criminals/thieves will be able to circumvent/disable the kill switch, trivially, within weeks (days ?) of the introduction. Stolen phones will still have value, and theft will continue. Bank on it.

2\. The kill switch will be used against legitimate users.

3\. Phone manufacturers, who were against the kill switch, will find a hidden value in tying the kill switch to rooting, and using kill switch laws to impede rooting activities. If it's illegal to de-kill-switch, but legal to root, all you need to do is make it impossible to root with the kill switch in place. Presto!

<comment><USER10> One, not all criminals who steal phones know anything about using a phone, and unless there's a guarantee that the kill switch is actually disabled nobodies going to take that chance of buying it off of you. It also makes the process more time consuming and error-prone, and seeing as the kill-switch is something someone can do right after they realize their phone is stolen, it'd be on a limited time basis. It makes the entire thing less worth it.

Two, it says _RIGHT IN THE BILL_ that the phones are _required_ to have an opt-out and disable feature, and they have to prompt the user to enable or disable when the phone is first setup, with the option to enable or disable at any later time.

Instead of spreading FUD, read the actual bill.

</comment></comment><comment><USER3> This is a rather irresponsible article. The bill as passed by the CA legislature [1] addresses this possibility. In section 2, Section 22761(e) of the code limits the scope of law enforcement use in accordance with section 7908 of the Public Utilities Code [2], which prohibits interruption of communication by law enforcement in anything other than a hostage or barricade situation, ie an ongoing standoff between police and criminals or another situation involving immediate danger of death or great harm (but requiring court submissions within 6 hours). Any other situation, including one where public safety is concerned (such as a protest) requires a warrant to be obtained in advance, subject to quite stringent conditions designed to limit the scope of the communications interruption. You should read it in full to understand all provisions, rather than relying on this summary.

Now, this set of rules is not perfect and could conceivably be abused by police or some other entity. But the cdt.org story ignores these rules completely and leaves readers with impression that legislators wither haven't thought about it or don't care. In reality the law is designed to prevent exactly this kind of abuse.

1\. [http://leginfo.legislature.ca.gov/faces/billNavClient.xhtml?...](http://leginfo.legislature.ca.gov/faces/billNavClient.xhtml?bill_id=201320140SB962)

2\. [http://www.leginfo.ca.gov/cgi- bin/displaycode?section=puc&gr...](http://www.leginfo.ca.gov/cgi- bin/displaycode?section=puc&group=07001-08000&file=7901-7912)

<comment><USER11> You're not considering the second-order effects. Sure, the law in Cali says police must do X, Y and Z before killing the phones. But the phones already have the kill switch; and, because of convenience, all phones sold in the country will have this kill switch. Now what's to prevent the police in, say, Ferguson MO to just nuke everyone's phones in a region? California law doesn't apply in MO, and the police there will be free to do whatever they want with this switch.

<comment><USER10> Counter-argument: If what you're saying is really how the law works, then why is CA attempting to pass this at all? By your logic, if they _don 't_ pass it then they can use it all they want, but if they _do_ pass it then there are restrictions.

The entire reason for attempting to pass a law like this is because it's assumed it would be illegal for the police to do it without a law passed specifically saying they're allowed to (Like everything else). If the police in MO did this, they'd have tons of lawsuits against them.

<comment><USER12> The argument is that they would have to pass the law first to compel the manufacturers to implement the switch in every phone. Then any other agency outside that law's jurisdiction can take advantage of the presence of the switch with little oversight.

It would still likely result in lawsuits anywhere it was used regardless of the law.

<comment><USER3> That doesn't explain why the bill includes all the restrictions on government, though. If the aim was to empower government, they could simply have been omitted.

<comment><USER12> I haven't seen anyone claim the bill empowers the government implementing the law beyond what it states.

The bill includes restrictions on the government at the level that falls within the jurisdiction of the law. The argument is what about jurisdictions that have no such law nor restrictions and take advantage of the existing hardware feature?

If we're talking Federal law then what you say makes sense, but as far as I know this is about a state law.

</comment></comment></comment></comment></comment></comment><comment><USER13> Surrounding ourselves with devices we cannot trust can be detrimental to us, especially if they are being backdoored, contain malware or are used against us. I'm starting to realize the only solution is open source hardware + software. There might be no other way. How else could we trust a device if we cannot inspect it?

<comment><USER14> Check out [http://www.lowrisc.org](http://www.lowrisc.org)

"lowRISC is producing fully open hardware systems. From the processor core to the development board, our goal is to create a completely open computing eco- system."

</comment></comment><comment><USER15> "California "Kill Switch" Bill Could Be Used to Disrupt Protests"

As if it were designed for any other purpose other than control. When did preventing stolen phones become such a hot button issue?

<comment><USER2> As a critic of the bill, I'll readily concede that smartphone theft is a major problem. It's one of the most prominant crimes in urban areas, costs billions of dollars a year, and has in several occassions caused violence.

Still, it doesn't justify a mandatory kill switch (there are a large number of free apps you can download), and it certainly doesn't justify letting police use kill switches that are installed.

<comment><USER11> This theft could be eliminated __today __: let there be a shared registry of stolen IMEI codes. Problem solved.

<comment><USER16> Many devices allow changing IMEI codes. See [https://www.google.com/search?q=imei+code+change](https://www.google.com/search?q=imei+code+change)

<comment><USER17> Furthermore, _not allowing_ an identifier such as IMEI to be changed is a potential privacy problem!

</comment></comment></comment></comment></comment><comment><USER18> "Could"? I give it 5 years.

How do people see this as a good idea? There are already voluntary methods for this, so there is literally no good justification for forcing a state- controlled version on everyone.

<comment><USER19> The advantage to mandatory and default-to-on is that it will be _prevalent_ and will therefore decrease the expected value of mugging someone for their phone. That is a legitimate benefit, and is not worth nothing. I'm still not happy about the trade-off, if the disable doesn't depend on an owner- controlled code or similar.

<comment><USER20> Fifteen years ago people were stealing mock-ups and pretending they had cell phones. I'm not sure those that commit felonies subscribe to the same value chain that you do.

Besides, assuming the device doesn't self-destruct Mission Impossible style, at worst it'll still be worth parts to someone. So there will be many more parts available--and possibly more victims to make up the difference (assuming muggers are working for something).

<comment><USER19> You can't possibly believe those are reasonable points.

<comment><USER20> What--that trying to stop an opportunistic crime with white market reason is idiotic?

<comment><USER19> Inasmuch as that is even coherent, yes.

<comment><USER20> Assumption: A Kill Switch will render a $500 device worthless, and thus eliminate the incentive for theft.

So, a couple of theft cases to frame: 1\. People steal fake phones (shiny objects) that have NEVER worked, ie aesthetic value only. 2\. Parts, such as replacement screens, are in great demand, and there are small urban retailers today that enjoy every opportunity to lower their costs, ie $5-50.

Following 1991 crime statistics, over 2/3 of those arrested for robbery tested positive for a controlled substance. Does an addict have Free Will? Delayed gratification? What's a $100/day habit like? What is an addict willing to do for a Klondike Bar? (Answer: Anything.)

<comment><USER19> _" Assumption: A Kill Switch will render a $500 device worthless, and thus eliminate the incentive for theft."_

That is clearly wrong, but it is not the assumption. The "assumption" (and not a very big one) is that a kill switch will substantially _reduce_ the value of the device, which will _reduce_ the incentive for theft. And that's almost certainly the case.

 _" Following 1991 crime statistics, over 2/3 of those arrested for robbery tested positive for a controlled substance."_

What percentage of the population at large would "test positive for a controlled substance"? Particularly in the demographics in question (young and risk-taking)? That's not a terribly meaningful figure. _Some_ portion of these crimes doubtless are drug related, some portion of those crimes would likely still occur. So? If we can get rid of some other crimes that's still a boon (and may, as I've said, nonetheless not be worth the trade-offs).

 _" Does an addict have Free Will?"_

In a meaningful sense, less than the rest of us, but that doesn't mean they're going to react the same regardless of circumstances. If robbery is _working less well to get them their fix_ then it certainly seems like they might be less likely to pick robbery next time. For those that _do_ respond by engaging in more robberies to pay for a fixed cost habit, they are more likely to get caught as they are forced to attempt more difficult opportunities and leave more of a pattern.

Flip it around. Say phones were cheap, and someone was proposing something to artificially make them more valuable to criminals. Would you think that likely to make the number of robberies go down, up, or not move?

<comment><USER20> Robbery has been trending down since the 90s. What was being stolen before the proliferation of cell tech during the 2000s? I think it's clear cellular phones do not cause theft. Though, I do think those robbed, are robbed of all of their valuables. I also think it's clear that those robbed were targeted, and a valuable phone suggests other valuables. I also am aware of existing parts markets including eBay and traditional retail. Will this Kill Switch render a device worth less than its weight in copper? Probably not. "I want your wallet, watch, and such--keep the phone."

I think if we were actually serious about victims, instead of using that warrant for a Kill Switch, we'd use it to query the networks and track the breadcrumbs; it's even richer than metadata sourced from billing systems. (It works for finding missing hikers.) And I'm pretty sure existing law covers this already.

<comment><USER19> People don't _carry_ much of value any more except their electronics. Before the 90s, people carried more cash, more regularly.

 _" I think if we were actually serious about victims, instead of using that warrant for a Kill Switch, we'd use it to query the networks and track the breadcrumbs"_

I don't know that I'd object to that. I'd still demand an owner-provided code. Note that I've never been saying "this system is amazing and exactly what we want", I've been saying "there is a legitimate up-side" \- which I stand by, and which the existence of better alternatives don't undermine.

<comment><USER20> If something is better than nothing, instead of expending capital on owner- supplied code infrastructure, why not pay robbers not to rob? That way, there's greater chance the owner is alive to use their device. (I'm thinking more control for you.)

And people carry much of value besides electronics today. You can use NYC seizure records and ATMs as proxies.

<comment><USER19> _" If something is better than nothing"_

Of course something is better than nothing in the one dimension where it's something rather than nothing. I've never been arguing that this is the best solution or even a desirable solution. I've been stating (repeatedly) that there's a dimension (that doesn't involve being recipient of the contracts or similar) along which it's a positive thing. This was in answer to the strong statement, _" How do people see this as a good idea? There are already voluntary methods for this, so there is literally no good justification for forcing a state-controlled version on everyone."_

 _" why not pay robbers not to rob?"_

Depends what you mean. A benefit solely for people who would otherwise rob seems obviously impractical - how do you verify that 1) they would rob absent the money, and 2) they refrain from robbing after you've given the money? Something broader like a Basic Income is actually something I favor, though I'm not certain that it will have a tremendous value in reducing robbery (though that's certainly conceivable).

 _" And people carry much of value besides electronics today. You can use NYC seizure records and ATMs as proxies."_

You'll have to expand on this. Note that my argument was not "no one _ever_ carries anything of significant value", but that the _typical_ (black market) value of what's carried by even wealthy individuals has fallen if you exclude electronics.

<comment><USER20> Is nothing finite, infinite, undefined, or? What you're calling "nothing" is actually everything not in your artificial construction.

If we unpack "nothing" further, we'll find any number of 'somethings' that are worse than what you're attempting to measure and affect. That's what we call Unintended Consequences, and not simply tautology or Begging the Question.

It is far from clear that this measure will have any significant affect on crimes such as robbery. And if we begin to unpack the "something" we quickly get to questions like, "Is it really a good idea to design a method for centrally destroying critical communication infrastructure?"

Following your logic, shouldn't we expect more robberies to make up for lost revenue?

If you're still in search of "cause", I'd suggest that the rate of robbery is inversely proportional to the typical waist size over time, i.e. we're wealthier now than we were.

<comment><USER19> This has gotten even more inane. You ignore things I've said, attribute to me things I haven't, and generally aren't making a lot of sense. I'm done with this thread.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER21> This makes zero sense. Why would they brick phones, costing each user (and likely themselves when the users sue) hundreds of dollars in damage when they can easily disrupt phone service in an area for a controlled period of time or block specific subscribers at the telco?

Note that the kill switch operates at a per phone level, so they would have to identify every user at the protest they want to brick, at which point there are better ways to handle the situation.

<comment><USER22> > _Why would they brick phones, costing each user (and likely themselves when > the users sue) hundreds of dollars in damage when they can easily disrupt > phone service in an area for a controlled period of time or block specific > subscribers at the telco?_

Because they can demand that power and have it offered to them?

<comment><USER21> Read the second half of the sentence you quoted.

<comment><USER22> What makes you think I didn't read it?

That was exactly my point in answering it: the fact that there is another, already existing, way to effect the same thing, doesn't negate the fact that police often demands whatever they can get away with, even if its superfluous.

It's just another capability to block phones that they can have, and if they can have it without needing to even ask a telco to do it for them, even the better.

</comment></comment></comment></comment><comment><USER4> Won't kill non-phone devices. Those aren't as numerous, and maybe not as real- time, but they're very difficult to shut down.

<comment><USER23> The problem is, how many people actually carry non-phone devices? There are a small handful of folks who carry around SLRs or iPod with cameras, but not many. (Since Google glass is paired with a phone, I'm guessing it would be bricked as well.)

I'm also curious if "Airplane Mode" defends against shutdown. While common sense says it should, it's an easy loophole for the thieves who are (ostensibly) the purpose of the shutdown switch.

<comment><USER24> The resale value of a phone that can never be taken out of Airplane Mode is going to be pretty bad, especially if it's "will instantly brick when you touch the setting", so it doesn't seem like much of a loophole for the anti- theft goal.

<comment><USER20> The loophole is handset exchange at the local retailer.

<comment><USER24> Wouldn't they check the phone against the list of stolen phones, or at least make sure the thing works as a phone, before accepting it?

<comment><USER20> Returned devices often do not work--that's why they're being exchanged.

Also, just on the carrier's corporate retail side (small in comparison), we're talking about over 2,500 locations, over 25,000 reps, and over 500,000 new monthly adds and upgrades. Serialization is very expensive and does not eliminate the tricky human.

Also, even a disabled device is still worth parts.

<comment><USER24> I don't think I understand what you're proposing.

Before, I thought "handset exchange" would be something where you bring in an old phone to get credit towards buying a new one. Like trading in a car. And like trading in a car, they'll want to make sure the old phone is actually worth something before they buy it from you.

Now... you're proposing a warranty exchange? Surely they check to make sure the device is actually eligible for the warranty (i.e. that you bought it, and within a certain timeframe) before they accept it?

Or is it something else entirely?

The fact that it would be worth the value of the parts is a good one, but not related to the question of whether Airplane Mode makes for a loophole.

<comment><USER20> Within 14 days, anyone can cancel or exchange.

So, here's an overly complicated example: 1\. Steal Nexus 5 2\. Buy Nexus 5 from local retailer 3\. Exchange the back from the stolen Nexus 5 with the clean Nexus 5 4\. Return stolen Nexus 5 for full refund

What if they try to power-up or troubleshoot the stolen Nexus 5? While you're exchanging the back, damage the power leads.

<comment><USER24> I assume the back is where the serial number lives?

Seems like that would work... once. The ID and credit check requirements would probably not make it a viable long-term solution though.

And, again, irrelevant to Airplane Mode.

<comment><USER20> I don't care about Airplane Mode--if the device has been killed, why would one wish to power it on?

So, what about prepaid? No credit check or ID required. One just requires front money.

Also, keep in mind that the carriers have been fighting Identity Theft and handset upgrades for quite some time. For instance, people steal an identity and use it to get 5 free handsets. This is a on-going problem. Identity is a hard problem.

Also, a swap doesn't even require a purchase--just sleight of hand. If we go through the sale process, if the rep turns their back, I may be able to swap.

And this doesn't even take into account inside activity. I worked at T-Mobile for 8 years, starting as a part-time sales rep and ending a senior manager of business process. During my time, we fired the entire market of Houston twice.

There are many types of thieves, but in the case of those attempting to support a habit, with their will, they will find a way. Some claim they have no choice.

Finally, don't assume a perfect system. Telecom is a mess.

<comment><USER24> Apologies, I thought you were continuing the original discussion of how Airplane Mode could provide a loophole.

Anyway, the system doesn't have to be perfect. If you significantly raise the barrier to turning stolen phones into cash, you'll significantly reduce the rate of theft.

<comment><USER20> Even if it were possible to raise the barrier on turning stolen phones into cash, it does not follow that it will reduce the rate of theft in the least. Do you think those that risk so much for so little are just going to roll over and die? Did you not learn the lesson of Whac-A-Mole?

If you really care about the victims, you'd use the warrant not to attempt to render tools to trash dumps, but instead use the warrant to query the networks. You know, perhaps give SWAT something legitimate to do... That seems like a deterrent for future thieves and a way to catch current thieves; or at least easier than catching copper thieves.

<comment><USER24> Crime is subject to supply and demand like everything else. Reduce the reward, reduce the activity.

The argument could be made that you'll merely shift theft into other areas rather than reducing it overall. But it's real hard to make the argument that making it hard to fence stolen cell phones won't reduce _cell phone_ theft is a pretty hard sell, especially if a carnival game is the best argument you have.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER25> There's just too many backdoors in smart phones. That's why I choose to use standalone hardware that can work with any phone for my voice encryption project:

[http://techcrunch.com/2014/07/31/jackpair/](http://techcrunch.com/2014/07/31/jackpair/)

<comment><USER26> I don't think I see the relevance. This article isn't about spying on you, it is about disabling your phone remotely ("kill switch," etc). How does encrypting your voice before it enters your phone mitigate that?

Plus if you're paranoid enough to use that then frankly you're too paranoid to own a cellphone at all. They can still use it to track your location and to remotely turn on the microphone and eavesdrop on the background sounds.

<comment><USER27> Commenter created that company he's linking to...there is no relevance to this article!

"JackPair: protect your voice phone calls from wiretapping by Jeffrey Chang & the AWIT team"

<comment><USER28> The commenter did mention that:

> _my_ voice encryption project

</comment></comment></comment></comment><comment><USER29> This reminds me of Apple's patent to remotely disable protester's (cellphone) cameras: [http://www.zdnet.com/apple-patent-could-remotely-disable- pro...](http://www.zdnet.com/apple-patent-could-remotely-disable-protesters- phone-cameras-7000003640/)

</comment><comment><USER17> It seems silly to disable individual devices with a remote "kill switch", when perhaps you can just do something at the network level: like block all but emergency calls, and instant messages, which coming via all the cell base stations in a given geographic area, which can be done without the inconvenience of sending configuration changes to large numbers of devices, based on where they are. There is still Wi-Fi. But most of that is connected to land lines going to telcos, with whose cooperation that could be blacked out also.

</comment><comment><USER30> Are there past, current, or future projects for launching networks w/in low earth orbit? I think it'd be effective to create an LEO, raspberry pi network for instances such as these. Remember when Libya turned off phones and the internet to stop unrest? People thought it was ridiculous and would never happen here. We're on that trajectory.

<comment><USER31> you either comply with amateur radio restrictions (probably not what you have in mind; no encryption, licensing, etc), or you comply with FCC rules & regs. or just break a bunch of laws.

from a technical standpoint, the amateur radio folks have tossed up repeater satellites in the past. see AMSAT.

</comment></comment><comment><USER32> "Police could use the kill switch to shut down all phones in a situation they unilaterally perceive as presenting an imminent risk of danger"

That's only one step away from the use of an EMP to isolate a crowd of people from the Internet (and each other) in Cory Doctorow's "Homeland" (I'm not a teen reader but I enjoyed it anyway)

<comment><USER33> Yeah. Keep in mind those phones are bricked forever. It is probably much easier to disable phone service in a certain region from the network side. I would imagine people suing the police for destroying their phones.

<comment><USER34> I seriously, seriously doubt 'bricked' forever. Unless the hardware actually overheats, it'd be possible to replace the relevant parts with cheap China imports.

<comment><USER35> I haven't seen anything like it in the US. But I spent some time in China, and at the local grocery store close to my apartment, there were a couple of teen- aged looking kids with a hot-air soldering station and some smt stencils who were re-working cell phones (probably failed QC) in their spare time when they weren't selling sunglasses or wristwatches and that kind of stuff.

</comment></comment></comment></comment><comment><USER36> Also, cops in California will be issued guns that they may use to arbitrarily murders citizens.

<comment><USER24> Such things are used _much_ less casually, though. There is immense public pressure not to misuse guns that isn't there for other stuff. Obviously guns are not _immune_ to misuse, but it's not all that common. "Less lethal" weapons like tasers and batons and rubber bullets and tear gas get misused way more frequently, precisely because they're less harmful than a regular gun. It's likely that the same thing could apply to a cell phone kill switch.

<comment><USER28> The argument will be that you don't "have a right" to cell service everywhere at anytime. "It's not like your service isn't restored after the protest."

<comment><USER37> Doesn't the kill switch permanently disable the phone?

Edit - Nope. I just reread the bill. Sorry for any misinformation:

"prevent reactivation of the smartphone on a wireless network except by an authorized user"

</comment></comment></comment></comment><comment><USER38> Call Gov. Brown (916) 445-2841 and let his staffers know how you feel. This is SB962.

</comment><comment><USER39> Seems like the first time this happens it can be easily challenged on free speech grounds, right?

</comment><comment><USER40> In New York we already have a kill switch. It's called AT&T.

<comment><USER12> Don't be silly, that's a nationwide feature.

</comment></comment><comment><USER41> Does this include access points like the MiFi hotspot?

</comment><comment><USER42> This article is FUD.

From the actual bill:

"This bill would require that any advanced mobile communications device, as defined, that is sold in California on or after January 1, 2015, include a technological solution, which may consist of software, hardware, or both software and hardware, that can render inoperable the essential features of the device, as defined, when the device is not in the possession of the rightful owner. The bill would require that the technological solution be able to withstand a hard reset, as defined. The bill would prohibit the sale of an advanced mobile communications device in California without the technological solution being enabled, but would authorize the rightful owner to affirmatively elect to disable the technological solution after sale."

<comment><USER2> Also from the actual bill (which the post includes a link to in the first line): "Any request by a government agency to interrupt communications service utilizing a technological solution required by this section is subject to Section 7908 of the Public Utilities Code."

The bill gives direct authorization for police to use this mandatory kill switch, so long as it complies with PUC Sec. 7908, which includes an emergency exception where police don't need court approval.

<comment><USER42> Ah! This wasn't in the version of the bill that I googled (first result when searching 'sb962' showed me the original bill).</comment></comment></comment>


The Companies Worth Less Than Facebook - <AUTHOR> http://larrycheng.com/2011/01/12/the-companies-worth-less-than-facebook/ <comment><USER2> It's important to note that stock valuations are derived from the expected future profitability of a company. Stock is a claim on future profits. Compared to a company like Halliburton, who has to build billion-dollar oil rigs before they make any profit, a technology company like Facebook is a lot more lucrative and thus its stock can inflate quickly if the profits expand faster than costs. And generally technology costs go down over time while profits increase exponentially. So you have a powder-keg scenario in Facebook if, and only if, they find a profitable business model based on their enormous userbase. And they better find that business model or the stock will crash like it's the year 2000.

<comment><USER3> According to their PR they have found such a business model and are now profitable.

<comment><USER4> "profitable" != dstein's "powder key scenario".

I will totally believe they are profitable, I do not believe that right this second they are bringing in enough to justify a $50B valuation on that ground alone.

</comment></comment></comment><comment><USER5> I wonder what the Fortune 500 would look like if people were to guess at which companies were more valuable than others.

<comment><USER3> That's pretty much what the stock market is and also the Fortune 500. It's all people guessing as to the future guesses of what a company is worth.

<comment><USER6> I guess the OP's comment should be reworded _"people who haven't put their money in it"_

<comment><USER3> Thats the great part about a public market. Anyone may speak as long as they put their money where their mouth is. (Or conversely put their mouth where their money is, aka. talking your book)

<comment><USER7> Which is not the case with facebook. (not that I'm disagreeing with you)

</comment></comment></comment></comment></comment><comment><USER8> I won't buy this until FB goes public and we see how it fares in an open market. Though I won't argue against the current valuation, I'm not sure I believe it yet.

<comment><USER6> Facebook shares are being traded quite a bit now. YOu could call it a semi public market.

<comment><USER9> "Public," in this case, I believe, includes the need for them to disclose earnings reports.

</comment></comment></comment><comment><USER10> Wow... neat list. FB is not more valuable than BMW, AIG or Nokia. There's just no way. And if it turns out that they are, then something is fundamentally wrong.

<comment><USER11> Why? I barely use facebook and it's more important to me than BMW or Nokia, and AIG should be out of business (but that's another argument). I assume facebook is more important to most people than BMW or Nokia, and though the value may be less per person it could be easily be more in aggregate.

<comment><USER10> I would think that hundreds of years of engineering (mechanical and electrical) and solid products used all across the globe would be more valuable than a social website, but maybe I'm wrong.

<comment><USER12> You are presuming the stock market is somehow fair.

<comment><USER10> Yes, you are right. I was confused. BMW engines deliver pigs to markets so people can eat. One can buy and sell virtual pigs on FaceBook by playing Farmville.

To me, actual bacon is more valuable than pretend bacon.

<comment><USER13> How "important" work is is only one factor in the creation of value. How much you produce, how it is valued by other people, what your margins are, what your future revenue streams will be -- these things are all factored into company value.

There are many companies that make non-essentials that are valued more highly than farms and utilities.

<comment><USER7> Exactly. Not to mention the fact that facebook is near monopoly status. If you were to add every single car manufacturer together, surely you'd get a much high valuation.

If the social network space were as diverse (in terms of relative player weight, not total number of players), we wouldn't be having this discussion.

Facebook's valuation reflects the value of the social-networking _market_ perhaps more than its value as a single business?

</comment></comment></comment></comment></comment></comment></comment><comment><USER14> One of the major component of stock valuation is the expected growth of the company, which somewhat accounted for market and internal 'risk'. However, I would argue that in Facebook's case the risk is higher than what is used for this valuation. Therefore, I do not see Facebook being worth more then say Target.

</comment><comment><USER15> I thought EMC bought VMWare?

<comment><USER16> They did, in 2001.

</comment></comment><comment><USER17> Market cap / valuation comparison is only meaningful if you compare companies in the same industry. For example, priceline.com has market cap of about $21B. In that respect, facebook valuation is not so high.

<comment><USER18> Umm, no. Exactly the opposite. If the market caps in one industry were wrongly valued relative to another, then investment would move (b/c there would be opportunity for arbitrage and profit).

Why did you think the economy was divided into separate and unrelated sections?

</comment></comment><comment><USER19> Facebook should use the same brilliant strategy that AOL did, and buy out a clearly sustainable big name company.

Maybe BMW, how about that?

</comment><comment><USER20> NewsCorp?....well it is final....Facebook won

<comment><USER21> on paper of GS & DST analytics they certainly did</comment></comment>


Lessons from the 1990s Bubble- don't get big fast. - <AUTHOR> http://www.strategy-business.com/press/article/07102?pg=1 <comment><AUTHOR> Or put another way, perserverance has resulted in business success... for those who had a long term strategy.

The herd instinct is dangerous.

High Tech startups are less likely to fail (though the %48 figure was "companies seeking VC funding" it doesn't break down how many got it. Possibly, those who did not get it had a lower failure rate.)</comment>


More Evidence Eating Hot Peppers Reduces Morbidity - <AUTHOR> http://nymag.com/scienceofus/2017/01/scientists-find-more-proof-eating-hot-chilis-may-extend-life.html <comment><USER2> Original title: "Scientists Say There's More Proof Eating Hot Peppers Could Prolong Life"

Morbidity != _Mortality_.</comment>


Take It to the Limit - <AUTHOR> http://opinionator.blogs.nytimes.com/2010/04/04/take-it-to-the-limit/

<comment><USER2> A mind-bending piece for those that want to re-live high school mathematics. Loved it. Now time to get back to work</comment>