Irreversible effects on female brains from soy products - <AUTHOR> http://news.ncsu.edu/news/2008/07/wmspatisaulneurotox.php

<comment><USER2> I look forward to more research in this area, but note that the "female brains" in the title refers to laboratory rats, not humans. Just about everything fucks up laboratory rats; it's not the smoking gun the headline suggests.

<comment><USER3> It may not be a smoking gun, but there is definitely smoke around phytoestrogens in soy products. There have been a few human studies in Japan that indicate reduced testosterone in men, and other effects in women. Though some studies have also indicated positive impact...reduced cancer risk and hints of greater longevity being the most impressive.

Perhaps alleviating some of the alarm, many soy products have drastically reduced levels of these compounds (tofu) or practically none at all (tempeh, real fermented soy sauce), and in these cases the benefits of soy (high quality protein, no cholesterol, low fat, etc.) almost certainly outweigh the negatives, compared to almost any other source of protein (meat, for example, becomes quite carcinogenic when grilled or cooked in pretty much any way that produces browning or blackening in the meat, in addition to containing cholesterol, no fiber, and lots of "bad fats").

So, while I'm not cutting tofu and tempeh and good soy sauce out of my diet, or even reducing it (I'm a vegetarian, and it's a staple of my diet), I avoid any form of raw soy: soy flour, edamame, soy milk, etc.

Also worth noting, soy in the forms that Americans most often consume it is a new phenomenon. Soy was considered inedible until the past 20-25 years, and it's only through extremely heavy marketing and lobbying pressure that soy has become part of every Americans diet (whether they know it or not, in cereals, in breads, in oils, and dozens of other places you would never think to look). In the cultures where soy has been consumed for hundreds or thousands of years, it has been in processed forms: tofu, tempeh, and soy sauce. Though young salted soy beans (called edamame in the west) are a popular snack in Japan and a few other places. Anyway, I'm suspicious of any food that has been foisted on me by huge corporations...and soy popularity in America is very much the result of a major corporate push. Corn is another fine example of money making for dangerous agricultural policy, leading to serious nutritional problems for a large segment of the population.

<comment><USER4> There's been so many studies in the news about so many compounds that jiggle your risk of this or that disease (usually cancer) up or down that I have decided to just live a normal life and not worry about it while avoiding obviously stupid things (like smoking tobacco regularly or ingesting plutonium).

Then again, I usually find myself in the minority in any internet discussion.

</comment></comment></comment><comment><USER5> A blogspot blog plastered with ads doesn't ooze with trustability. I'd like to see a better source before I believe this.

<comment><AUTHOR> I found these too: <http://www.physorg.com/news136738827.html> [http://www.sciencedaily.com/releases/2008/07/080731140030.ht...](http://www.sciencedaily.com/releases/2008/07/080731140030.htm) and the paper: <http://lib.bioinfo.pl/pmid:15053943>

But actually I posted this here because I wanted some expert here to comment on the article, as it worried me a lot.</comment></comment>


A critique of "How to C in 2016" - <AUTHOR> https://github.com/Keith-S-Thompson/how-to-c-response <comment><USER3> > Zeroing memory often means that buggy code will have consistent behavior; by > definition it will not have correct behavior. And consistently incorrect > behavior can be more difficult to track down.

I agree that using calloc should not be an excuse for writing sloppy initialization code. But in my experience, inconsistently incorrect behaviour (e.g. heisenbugs that tend to appear and disappear depending on the content of some random chunk of uninitialized memory that happens to be in an unfortunate state after malloc) are one of the hardest type of bugs to fix. It's the type of the bug that occasionally happens in production and typically can't be reproduced in a controlled manner in a development environment. I certainly prefer consistently incorrect behavior.

<comment><USER4> The tools for rooting out these problems have gotten a lot better, thankfully. I'm very fond of the address sanitizer. Using calloc() everywhere can prevent the address sanitizer from finding problems.

<comment><USER5> GCC (>=4.8) & Clang now have Address Sanitizer support for fast memory error detection. About a 2x slowdown [1].

0\. [https://github.com/google/sanitizers/wiki/AddressSanitizer](https://github.com/google/sanitizers/wiki/AddressSanitizer) 1\. [https://github.com/google/sanitizers/wiki/AddressSanitizerPe...](https://github.com/google/sanitizers/wiki/AddressSanitizerPerformanceNumbers)

</comment></comment></comment><comment><USER6> Ironic that he begins by taking issue with the idea that you should avoid writing C if you can, then proceeds to provide the best evidence possible for why it's true. Why on Earth would you voluntarily code in a language where people can debate something as simple as which type to use for integers, unless you absolutely had to?

<comment><USER7> Because it's simple and low-overhead and compilers for it exist on every lump of hardware I've ever had to work with, from a clunky x64 to a PIC to a TigerSHARC to a bizarre DSP thingy from a tiny fab lab somewhere.

A great many of the problems that people experience with C code can actually be nullified (zing!) by finding a competent C programmer who does the job properly. A tool being easy to misuse doesn't mean we shouldn't use it; it just means we should demand high standards of the programmers and not employ some chancer who learned how to program from the back of a cereal packet. I give young children plastic safety scissors. I give competent adults chainsaws and scalpels.

<comment><USER8> The key phrase here is " _if_ you can avoid it".

When your target platform is an 8-bit microcontroller or an embedded system with hard real-time requirements, your options are very limited.

But there are plenty of situations where there are alternatives, and often these allow you to solve your problem in less time, with much lower risk of bugs than in C. As always in life, one has to evaluate one's options, consider their respective advantages and weaknesses and then make a choice.

If I had to write a document like that, I would use a different phrasing from "if you can avoid it". But the sentiment - to avoid using C where superior alternatives exist[1] - is something I agree with.

> A great many of the problems that people experience with C code can actually > be nullified (zing!) by finding a competent C programmer who does the job > properly.

That is kind of like saying the solution to traffic accidents is only letting people drive that don't cause accidents or demand of people that they drive sufficiently carefully. Sure, that is something worth wishing for - but it is not very realistic to expect this to actually happen.

Not that I disagree that C is a very demanding language. Even the best programmers make mistakes. But this is the reason the author of the original document the linked article refers to advised people to avoid C where possible. Most programmers will be better off for most of their projects with a language like Go, or Python or whatever.

[1] Of course, if by "alternatives" I mean languages like Perl, Python or Ruby, it is worth keeping in mind that their main implementations are written in C.

<comment><USER9> > When your target platform is an 8-bit microcontroller or an embedded system > with hard real-time requirements, your options are very limited.

You mean like the CPUs supported by MikroElektronika's Pascal and Basic compilers?

[http://www.mikroe.com/8051/](http://www.mikroe.com/8051/)

[http://www.mikroe.com/pic/](http://www.mikroe.com/pic/)

[http://www.mikroe.com/avr/](http://www.mikroe.com/avr/)

<comment><USER8> I get your point. However, I did not say there were _no_ alternatives, just that they were "very limited" (when compared to, say, Debian running on amd64).

</comment></comment></comment></comment></comment><comment><USER10> I disagree with many of the arguments. Many of them are ignoring the reality of today.

One example:

> If you want bytes, use unsigned char. If you want octets, use uint8_t

Bytes and octets are the same today. I never came across a system where this wasn't true. I was never told about a system where this wasn't true. I wasn't even told that there once were systems where this wasn't true until fairly recently.

<comment><USER11> >Bytes and octets are the same today. I never came across a system where this wasn't true.

The fact that all modern systems use eight bit bytes is no reason to assume that a byte is eight bits. The fact is that a byte is not eight bits large.

People may wish to run code on "historical" systems, and someone may wish to create a 9-bit byte system for fun.

To write C code with an assumption that things are one way, when the standard does not define this assumption, screams of unportable code. You might as well use GCC extensions - after all, for a long time, what would it matter? _Everyone_ used GCC, right?

<comment><USER12> By the same argument we shouldn't assume that bits have only two values - _what, you mean I can 't write C for my ternary logic computer?_

You need to make a decision about which simplifying assumptions you make - <USER2> has decided not to assume there are 8 bits to the byte. I think it's arguable that in 2016 this is not the best decision, and they could get rid of some cognitive overhead by making the simplifying assumption.

<comment><USER4> Unfortunately, there are real world systems with C compilers that do not have 8 bit bytes. It's easy to forget the embedded world.

C is one of the very, very few languages that you can reasonably expect to run on your weird embedded microprocessor, microcontroller, DSP, or whatever.

Bit, however, means "binary digit". That's the literal definition of the word. Historical usage of the word "byte" has varied.

<comment><USER12> > C is one of the very, very few languages that you can reasonably expect to > run on your weird embedded microprocessor, microcontroller, DSP, or > whatever.

I'm not an expert on DSP processing in any way, but I'd argue that if the environment is so peculiar that it doesn't have 8-bit bytes, you won't be able to use so many of the (formally optional) parts of C that you might as well call your code "weirdC" and do without char. It's not like you're going to use normal C libraries, and you are most probably relying on a specific compiler implementation and a lot of platform specific weirdnesses.

<comment><USER13> You can use char, and for the most part you won't notice any difference, until you start looking at the memory display in your IDE and have a short-lived WTF moment. A c-string looks strange in the memory view because there's a NULL octet between each character but that's an implementation detail that you don't really notice 99% of the time, because everything on the processor is designed to use 16-bit words. If you write a buffer of chars to the UART tx register, it will only put the half of the word with the character data onto the wire, just like with any other microcontroller, just like with PySerial, and just like with JS and websockets. That's why the C standard doesn't say a char is 8-bits, it just says that sizeof(char) is 1. I would argue that any code doing anything under the assumption that a char variable occupies 8 bits in memory and that the next char in an array is physically adjacent to it with no wasted space in between is just poorly-written and inherently not portable.

As for why this is the case, Generally DSPs are designed to do a few tasks very well (multiply-accumulate being the most obvious example, simultaneous reads from X and y memory, etc.) and are generally optimized for a specific word size. If you really need to access an octet on E.g. A 16-bit TI DSP you can, you just need to shift and mask. That's obviously not very efficient, because that's not really what it's optimized for. If that's what you really need, you picked the wrong part. You're gonna be filter-/FFT-/DCT-/whatever- ing way more 12 or 16-bit ADC samples per second, per dollar, and per milliWatt on that 16-bit DSP than you would be on your octet-addressable MSP430.

Regarding "Normal" c libraries, If they're valid C they should work just fine for the most part, With some obvious exceptions: you're not going to have a fun time with your "floats" on a processor without FP HW. That's why there's a standard, if you're not relying on undefined or implementation-defined behavior, you'll be fine(ish)

<comment><USER12> > I would argue that any code doing anything under the assumption that a char > variable occupies 8 bits in memory and that the next char in an array is > physically adjacent to it with no wasted space in between is just poorly- > written and inherently not portable

I don't think that's fair at all. It's well written and perfectly portable, _under that assumption_. If that assumption happens to hold for all the systems that could is meant to run on, why shouldn't you make it? Why assuming that unsigned integers overflow to 0 is fair, and assuming 8 bit bytes is not? They are both pragmatic choices. I think arguing that the C standard didn't make the best choice is at the least a reasonable position. Saying that people who disagree with you on this are writing bad code is not the right way to approach the subject, IMO.

> If they're valid C they should work just fine for the most part

I've yet to find a library that is valid C, in the strictest sense of the term - i.e., no floats or doubles, no 8-bit char, no uint8_t, etc. I'm sure there are, among libraries _meant to run on DSPs_. Does it make sense for them and libraries meant to run on bigger processors to adhere to the same exact standard? I'm not sure.

<comment><USER14> > If that assumption happens to hold for all the systems that could is meant > to run on, why shouldn't you make it?

Because what's going to happen two years down the road when you need to get that code working on a different platform.

(In the old days, they called that thinking "all the world's a VAX", which became "all the world's linux" in the not-quite-as-old days)

<comment><USER12> > Because what's going to happen two years down the road when you need to get > that code working on a different platform.

And what happens when the different platform handles overflow differently? Or has non-IEEE floats? Or breaks whatever assumption the C standard already makes?

Here's the thing: C is _already_ built on assumptions, which might or might not hold for a specific platform.

Choosing which assumptions we hold true is a pragmatic choice that must be done. C does it, and does it consciously - but it doesn't mean that it nails every choice.

<comment><USER14> If you're in a situation where you need specific implementation details of floating point arithmetic, then may the devil have mercy on your soul, because god certainly won't.

<comment><USER15> Wouldn't debugging / testability imply this is a fairly large proportion of programs? Having a calculation give different results on different hardware would make testing difficult: [http://yosefk.com/blog/consistency-how-to- defeat-the-purpose...](http://yosefk.com/blog/consistency-how-to-defeat-the- purpose-of-ieee-floating-point.html)

<comment><USER14> Your own link explains how easy it is to get different results even on the same hardware depending on compiler flags.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER16> I find myself to disagreement with almost ALL the points this "critique" makes.

They are either minor pedantic corrections, "it's how it's always been done" things, or "you might have your reasons for doing it in a bizarro way" affairs.

Sorry, but for 90% of use cases, the original article has better advice.

<comment><USER17> Agreed. Most of the integer stuff is pedantry ("doesn't make it non-standard" \-- who cares, the point being made was that these types are better). There are some valid and useful points being made, but most would serve better as caveats on the original article rather than straight out "don't listen to this".

</comment></comment><comment><USER18> Not to be confused with Ken Thompson.

<comment><USER19> Almost fell for that....

</comment></comment><comment><USER20> What's up with creating "empty" repositories for articles? Isn't there a better solution? I think using gist would be more suitable if you want the article to be attached to your github username...

</comment><comment><USER21> One of the most important reasons to use calloc, other than the zeroing of the allocated memory, is the fact that it checks for integer overflows (at least on most implementations).

For example, when allocating an array of n elements, in malloc you would do something like the following:

ptr = malloc(sizeof(int) * n);

Which could potentially lead to an overflow of the size passed to malloc, hence allocating a significantly smaller buffer and end up accessing adjacent memory which hasn't been allocated to the buffer (buffer overflow)

Calloc requires two arguments, one for size and one for number of elements, which allows it to check for an overflow before performing an allocation (e.g. by using SIZE_MAX):

ptr = calloc(n, sizeof(int));

This is not to say that zeroing memory is not useful. There are many situations in which a zero in a memory block represents the end of the usable data, as for example in a string, so zeroing memory in those situations is definitely recommended.

<comment><USER22> Using calloc instead of malloc, just for checking arithmetic overflow, is superfluous. You can always write a check or a wrapper for malloc that does that automatically. It is so easy I can write it here:

      _Bool Check( const size_t a , const size_t b )
      {
        if( a > SIZE_MAX / b )
        {
           return false;
        }
        return true;
      }

(If proper warnings are enabled, it also provides extra integer type checking.)

<comment><USER21> Agreed, but there's little point in reinventing the wheel in this particular case.

<comment><USER22> There is no reinventing going on here. In C you have to write relatively low level code. This includes manually calling allocs for objects, which includes the code for checking your arithmetic. At some point you will have to write that code. If you are smart you will wrap it into a function.

<comment><USER21> I don't see the point of the discussion, that piece of code (or relatively equivalent), is already being performed by a libC function (calloc, in this case), how is that less convenient than you writing it yourself?

It has nothing to do with how smart you are or how low level C is, you are effectively reinventing that part of calloc by wrapping malloc.

<comment><USER23> There's a point to be made that people _will_ be idiots and risk bugs for the sake of efficiency.

That's why OpenBSD has reallocarray(3) (which serves as a fine malloc, though the kernel not having reallocation has mallocarray(9))

</comment></comment></comment></comment></comment></comment><comment><USER24> > The first rule of C is don't write C if you can avoid it.

My C skills are non-existent, but it occurs to me while reading the response that when two people who have so carefully considered the subject can arrive at such different places... then yes, you probably shouldn't write C if you can avoid it.

<comment><USER25> C is the only language that will run on certain strange systems, and that is the only reason that most of these quibbles even matter. It's more of an argument of "What is the most portable way to write C?"

C is a very small and elegant language that never lies to you. There aren't any useless functions that are specific to one use case, and things that you don't really, really need are simply left out of the language. This means that instead of spending hours learning the language and all of its quirks, you get to focus on the problem that you're trying to solve, and come up with the most efficient solution possible (there's a reason why almost all performance tests use C as 1). You don't have any language quirks like those that are discussed in this article, unless you are running an architecture that has similar quirks, in which case you're going to have quirks no matter what you do. Edge use cases, as with everything, may cause a bit of quirkiness.

That being said, don't be scared off from C just because of these pedantic arguments.

<comment><USER26> >C is a very small and elegant language that never lies to you.

I've liked:

[http://www.gowrikumar.com/c/index.php](http://www.gowrikumar.com/c/index.php)

..and...

[https://www.google.com/search?q=expert+c+programming+deep+c+...](https://www.google.com/search?q=expert+c+programming+deep+c+secrets)

<comment><USER26> Also don't miss:

[http://blog.robertelder.org/7-weird-old-things-about-the- c-p...](http://blog.robertelder.org/7-weird-old-things-about-the-c- preprocessor/)

</comment></comment></comment></comment><comment><USER27> This, ladies and gentlemen, is why C gives me the willies. And why this happens:

[http://www.cvedetails.com/vulnerability- list/year-2016/month...](http://www.cvedetails.com/vulnerability- list/year-2016/month-1/January.html)

<comment><USER25> Those are due to programmer error. The fact that C doesn't lie to you means that it takes a bit more experience to program properly; as with all things, with great power comes great responsibility. You don't blame the gun for killing people, you blame the person for shooting it.

<comment><USER28> > Those are due to programmer error.

How does that help? Almost all security vulnerabilities are due to programmer error.

> You don't blame the gun for killing people, you blame the person for > shooting it.

It's more like choosing between a gun that makes it really easy to shoot yourself in the foot by accident and one that is safer.

</comment></comment></comment><comment><USER29> Reading this as someone who neither loves not loathes C, I would not have written this as a series of rebuttals. It makes the essay seem defensive and nit picky. I get more of a sense of emotional attachment to a particular way than any sort of reasoning.

</comment><comment><USER30> Aah, this felt like a much-needed piece. The original text was so long, it kind of made my eyes glaze over and I never found the time to do this level of detailed critique. Well done!

</comment><comment><USER22> >size_t is defined as "an integer capable of holding the >largest array index"

>>No, it isn't.

Could anyone elaborate?

I don't see how could someone allocate more than SIZE_MAX bytes with (m/c/re)alloc since they all take size_t as an argument, and size_t is the type used for defining array sizes. Thus size_t can hold the largest array index (in fact it can hold the largest_index+1 since arrays are zero based). Any counterarguments?

<comment><USER31> Maybe he's taking it very literally, as I think size_t is literally defined as 'the integer type of the result of the sizeof operator'. So it literally isn't defined as 'an integer capable of holding the >largest array index' as that's not the definition and words they use.

<comment><USER32> But if sizeof returns size_t, then your can't have indexes larger than that. Otherwise you could point beyond the largest in-memory object possible. (Using smallest (byte) indexing)

But yes, he may be arguing the definition rather than meaning.

</comment></comment></comment><comment><USER33> > Converting to uintprt_t will give you some result -- but that result won't > be useful. Unless you're writing low-level system code, don't do any pointer > comparison or arithmetic unless both pointers point into or just past the > end of the same object.

I disagree. There are situations where you need an ordering between unrelated objects, but the precise order doesn't matter, only that it's consistent.

An example is when you have a complex data structure with one lock per node, and you need to lock more than one node at a time for some algorithm.

To prevent a deadlock, you must always take the locks in the same order. Comparing the address of the locks gives you a total order over all the locks, which is enough.

<comment><USER34> I think comparing (using <) pointers to unrelated objects is undefined behavior. So you do not get a consistent ordering.

<comment><USER33> The part I quoted is talking about casting the pointers to uintptr_t (which is defined behavior) and comparing the resulting uintptr_t (since it's an integer, comparing it is defined behavior). It's not talking about comparing the pointers directly (which is undefined behavior). His argument is that, while defined behavior, "(uintptr_t)ptr_a < (uintptr_t)ptr_b" is useless; I disagree, since it's a well-known trick to prevent AB/BA type deadlocks.

</comment></comment></comment><comment><USER35> The discussion usually boils down to

a. We need a better C

b. We need better programmers.

Personally I believe C tries to hard to be high level instead of what it really is. Newer revisions should try to make it lower level. For example I never could understand why we need enums. Enums are very useful for Java or Golang which are high-level. C never needs enums. Why should I ever put const in the argument of a function? It makes sense for D but for C no. Why should I ever use complex in C. Is there any HW that supports complex numbers? If it becomes standardized, then why not?

C should be good to write kernels and simple utilities and simple compilers. For the rest, use a high-level language.

<comment><USER36> > For example I never could understand why we need enums.

> Why should I ever put const in the argument of a function?

Reducing potential state and conveying programmer intent. Both lead to safer and more performant code (by way of compiler optimizations).

<comment><USER35> What you say is incompatible with the "Cross-platform assemble", simple language ideals.

If that was the intent why not throw namespaces and other goodies in?

<comment><USER36> Well those ideals are pretty subjective, I'd say that the ideal language would be flexible, performant, safe and productive. As those goals conflict with one another, the ideal language would find the perfect balance. I don't know if C has found that balance, but it has had a pretty good run.

Defining sets (enums) and memory access constraints (consts). I wouldn't describe that as high level from a conceptual or practical perspective. Namespaces are simple conceptually but not in practice. The same can be said about the beautiful logical consistency of S-expressions.

</comment></comment></comment></comment><comment><USER37> Isn't another problem of "ptrdiff_t diff = (uintptr_t)ptrOld - (uintptr_t)ptrNew;" that you're assigning an unsigned value to a signed variable?

If ptrNew is larger than ptrOld this can give a very large value via wrapping around, so large that it will probably be bigger than the max value of ptrdiff_t, making the assignment a form of signed overflow.

<comment><USER22> The assignment is a conversion from unsigned to signed, if the value cannot be represented by the signed type, the result is implementation defined or an implementation defined signal is triggered.

<comment><USER37> Right. Implementation defined, not undefined. Still not great for portable code, which is what the article is all about.

<comment><USER22> It's also very dangerous.

</comment></comment></comment></comment><comment><USER38> I'm divided.

I think it is good to share our ideas and our theories with each other because the discourse can stretch our minds and help us better imagine the perspective of another. Dialogue can foster creativity and invention, and an honest argument can embiggen friendships like nothing else.

On the other hand, opinions are like assholes.

</comment><comment><USER39> > But zeroing a structure with memset, though it will set any integer members > to zero, is not guaranteed to set floating-piont members to 0.0 or pointers > to NULL (though it will on most systems).

Why is that? On those systems, is a sequence of 0 bits not considered 0.0f or NULL?

<comment><USER23> Not sure about fp, but the C standard very carefully and explicitly notes that NULL pointers doesn't mean a runtime value of 0. The comp.lang.c FAQ 5.17[0] further provides examples of nonzero NULL pointers e.g.

> The CDC Cyber 180 Series has 48-bit pointers consisting of a ring, segment, > and offset. Most users (in ring 11) have null pointers of 0xB00000000000.

This is a bit confusing because the "null constant" is an integral 0 e.g. `(void _) 0` is a null pointer, but it 's defined as an arbitrary compiler instruction. `(void _) foo` where foo is 0 at runtime may not be a null pointer at all.

[0] [http://c-faq.com/null/machexamp.html](http://c-faq.com/null/machexamp.html)

</comment></comment><comment><USER40> > int in particular is going to be the most "natural" integer type for the > current platform. If you want signed integers that are reasonably fast and > are at least 16 bits, there's nothing wrong with using int

The slight performance gain on a few systems that you get from using int rather than int16_t is very rarely worth the hugely increased risk of introducing platform-specific undefined behaviour, IMO.

> float and double are very commonly IEEE 32-bit and 64-bit floating-point > types, particularly on modern systems, but there's no guarantee of that in > the language.

True. Is there an alternative? Something like float32_t?

> But more often all you need is a particular range of values. For that, you > can use either the [u]int_leastN_t or [u]int_leastN_t types, or one of the > predefined types.

Sure - but again, how much performance do you gain from using a _leastN type, and how much reliability do you lose?

> It's capable of holding the size of the largest object your implementation > supports. (There's an argument that that's not necessarily guaranteed, but > for practical purposes you can rely on it.) It can hold the largest memory > offset if all offsets are within a single object.

But you just said in the previous section that it only makes sense to perform pointer arithmetic within a single object anyway.

> There is a widespread convention, particularly in Unix-like systems, for > functions to return 0 for success and some non-zero value (often -1) for > failure. In many cases different non-zero results denote different kinds of > failure. It's important to follow this convention when adding new functions > to such an interface. (0 is used for success because typicallyi there's only > one way for a function to succeed, and multiple ways for it to fail.)

The convention is not as widely accepted as this section implies. When adding to an existing system one should follow that system's conventions. When writing for Unix one should follow the Unix conventions. But there are other conventions (e.g. the VMS one) that also see use in C.

> I don't often use automatic formatting tools myself. Perhaps I should.

Yes, you should.

> Zeroing memory often means that buggy code will have consistent behavior; by > definition it will not have correct behavior. And consistently incorrect > behavior can be more difficult to track down.

Disagree strongly. Consistently incorrect behaviour is much easier to track down than inconsistently incorrect behaviour.

> if you're trying to program defensively, you might consider initializing > allocated memory to some value that's known to be invalid rather than one > that might be valid.

Agreed - but how? One of the biggest problems with C is that it is extremely hard to mark a state as invalid (hence the whole integers for error codes discussion earlier, where really an error code should have a different type from a valid integer result).

<comment><USER41> >The slight performance gain on a few systems that you get from using int rather than int16_t

int16_t is also unportable as he mentions later

>the hugely increased risk of introducing platform-specific undefined behaviour

What risk? Please explain how int introduces undefined behaviour.

>how much performance

It's not about performance. intN_t is NOT guaranteed to exist.

>But you just said in the previous section that it only makes sense to perform pointer arithmetic within a single object anyway.

Yes and that's right.

<comment><USER40> > int16_t is also unportable as he mentions later

It's theoretically unportable. I have yet to see a real system to which it's unportable.

> What risk? Please explain how int introduces undefined behaviour.

(Signed) integer overflow is undefined behaviour. It is very common to develop on platforms on which int is 32 or 64-bits. This carries a high risk of accidentally overflowing the limits of a 16-bit integer and not realizing. When you do this you don't notice anything (because it doesn't show up on your development machines), but you've introduced undefined behaviour that can easily manifest in practice on machines with 16-bit int.</comment></comment></comment>


BulldozAIR (YC S16) Is Asana for Construction Teams – AMA - <AUTHOR> http://themacro.com/articles/2016/10/bulldozair/ <comment><USER2> Hey guys, thanks for doing this! What did you like the most during your time at YC?

<comment><USER3> Hi,

Short answer: YC is the perfect excuse for international teams to get away from everyday routine!

We had half the team come from Paris to Cupertino with Ali and I. Living together in a house for more than 2 months changed a lot of things:

\- It was the perfect excuse for everyone to get away and completely focus on BulldozAIR (the company, the product). This allowed us to finally do the complete rewrites of part of our backend, for example (We had been postponing this on multiple occasions)

\- Splitting the team in two and working in different time zones forced us to be more effective, talkative and precise. When you have team members that know each other well, the hand-overs are pretty smooth and you get to see your product evolve 24 hours a day... priceless!

\- I loved the fact that all my external emails from France were stacked in my inbox when I woke up. This allowed me to answer them at once quickly and it felt like it was WAY easier to master my time for the rest of the day. With all that time "regained", Ali and I got to seat together and challenge everything like we used to when we began BulldozAIR. Understand that YC partners are really good at asking the tough questions and also tell you when you go completely off-track in your reasoning :)

Maxence, CTO @ BulldozAIR

edited for typo</comment></comment>


Think OS: A Brief Introduction to Operating Systems - <AUTHOR> http://www.greenteapress.com/thinkos/index.html

<comment><USER2> Hi All, Thanks for your interest in this book! It is a very rough draft, but I welcome comments and suggestions.

The code examples are not quite ready for prime time, but I will release them soon and update the (missing) link in the book.

<comment><USER3> You are really amazing and you are my hero

</comment></comment><comment><USER4> CC licensed as well as several other Think [blank] books by Allen Downey: [http://greenteapress.com/](http://greenteapress.com/)

</comment><comment><USER5> Allen B. Downey is doing a great work concerning free text books for Computer Science (Think [Stats|OS|Bayes|Python|Complexity]). Consider a donation maybe.

<comment><USER3> Apart from donation you can just buy the book :)

</comment></comment><comment><USER6> What is this book written in? I've seen this format for the xv6 textbook as well.

<comment><USER7> In LaTeX. Sources are linked from the page:

[https://github.com/AllenDowney/ThinkOS](https://github.com/AllenDowney/ThinkOS)</comment></comment>


Programmer Creates An AI To (Not Quite) Beat NES Games - <AUTHOR> http://techcrunch.com/2013/04/14/nes-robot/ <comment><USER2> FYI the video is worth a full watch. The author of the paper is painfully funny.

<comment><USER3> I can confirm it was well worth my 16 mins.

This really makes me want to go back to my game and play some more with AI. Although, at the same time I realize that's the mistake I made - making the game/platform for creating AI. It really takes a toll. This guy uses existing NES games, which allows him to focus on the AI and even generic game learning. Brilliant.

You can clearly see the advantages of AI in the short-term play (think in the order of milliseconds, exact frame-by-frame button presses) over anything a human could ever achieve.

Imagine combining the short-term button-mashing of said AI with the long-term planning of human players...

<comment><USER4> You're looking for the pleasingly-symmetric-to-AI acronym IA, for Intelligence Amplification: <http://en.wikipedia.org/wiki/Intelligence_amplification>

</comment></comment></comment><comment><USER5> Much better article here: [http://www.wired.co.uk/news/archive/2013-04/12/super- mario-s...](http://www.wired.co.uk/news/archive/2013-04/12/super-mario-solved)

The video is long but worth all 16 minutes. I like how he isolated such a dead simple heuristic for success in video games. It's not surprising, in retrospect, that "numbers going up" would correlate with winning, but to prove it in practice is pretty neat.

<comment><USER6> He isn't very explicit about it, but the "time travel" that is mentioned basically allows it to go back in time if things turn out badly. This is what allows it to make such unbelievable trick moves: in short timespans it is almost a brute-force search, but over the longer term it can't backtrack as much.

If that makes sense.

<comment><USER7> Brute force search with time in one dimension is equivalent to this "time travel", isn't it?

<comment><USER6> Yes, that is essentially what is happening.

</comment></comment></comment></comment><comment><USER8> Sounds to me like the next big improvement would be to give the algorithm a concept of boredom: If the numbers haven't gone up in a while, consider that very bad. Try progressively more crazy things.

For example, unpausing Tetris. Or having Mario run left.

<comment><USER9> > Try progressively more crazy things.

Teaching a computer various concepts of 'crazy' must be tons of fun! :-D

</comment></comment><comment><USER10> Pausing Tetris to avoid losing was hilarious.

<comment><USER11> "The only way to win is not to play"

<comment><USER7> "The only winning move is not to play."

The author is humorous, poetic, and brilliant.

<comment><USER12> and possibly a fan of WarGames :)

<comment><USER13> Exactly what I thought. I even think it was a clever way to end, and a point he might have been making as a sort of subtext.

<comment><USER7> I've never seen WarGames. After reading the synopsis, the subtext is undeniably intentional.

<comment><USER13> 30 year old movie spoiler alert!!!!

War Games: Very, very basically, from deep, deep memory...

A computer about to launch a global nuclear war is played at tic-tac-toe to learn it cant win. It deduces that the only way to win a nuclear war is not to start the thing in the first place. Any other strategy is a lose, or what we call mutually assured destruction.

Its obviously more complicated than that. Even though its 30 odd years old, it worth a watch.

<comment><USER14> <http://i.imgur.com/fSBsN7c.png>

want to play?

<comment><USER13> Nice :)

But no.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER15> Direct link to paper: <http://www.cs.cmu.edu/~tom7/mario/mario.pdf>

Direct link to video: [http://www.youtube.com/watch?feature=player_embedded&v=x...](http://www.youtube.com/watch?feature=player_embedded&v=xOCurBYI_gY)

</comment><comment><USER16> Just to note that the AI has complete access to the NES's RAM (and also backtracks whenever it gets into trouble), which is not quite fair to compare to other approaches to AI or playing against a human. I'd be pretty damned good at battleship if I could see your board and rewind whenever I missed.

<comment><USER17> yes, but the point is also that the program doesn't really know the goal, it just tries to increase bytes that look like counters. that's the fun thing.

you should compare it with a game whose rules you don't know, being able only to understand your score. like trying to play spider solitaire on windows without knowing how the game works (it allows you to undo your moves).

<comment><USER16> i agree that it is an interesting result, however having access to _everything_ is weird from an AI point of view and really muddies any conclusions to be drawn; the headline seems to make it sound like this is a breakthrough in AI, when it is using a cheat that won't apply to any sort of real situation.

notice that in your example of solitaire, _knowing_ the values of hidden cards really changes the nature of the game and makes playing the game much less strategic

<comment><USER18> Not sure why TechCrunch made it seem that way ("a breakthrough in AI"), when the author explicitly says he's submitted this to SIGBOVIK 2013 -- an April 1 conference that usually publishes fake research. (<http://sigbovik.org/2013/>)

It is clearly an April Fool's hack.

<comment><USER19> Good, I'm not the only person who suspected that.

This is from the paper. "I tried again, and it was a huge breakthrough: Mario jumped up to get all the coins, and then almost immediately jumped back down to continue the level! On his fi rst try he beat 1-2 and then immediately jumped in the pit at the beginning of 1-3 just as I was starting to feel suuuuuper smart (Figure 7). On a scale of OMFG to WTFLOL I was like whaaaaaaat?"

</comment></comment></comment></comment></comment><comment><USER20> Video is hilarious and worth watching the whole thing as others have mentioned, but there's some great stuff in the paper also. He mentions some really interesting future directions, e.g. obviating the need for the training data set of a human playing the game by having the computer initially try different sets of random inputs and continuously improving on those that do the "best" according to it's objective function. The bit about the computer trying to play "dinosaur coloring" is fantastic also.

</comment><comment><USER21> The day has come, "AI rage quits, passes Turing test."

</comment><comment><USER22> My favorite part was how the program finds glitches and uses them ruthlessly.

<comment><USER23> At university we had a contest with programmable tanks. Many wrote elaborate algorithms and tried to find the optimal strategy, but the winner was very crude: It tried to get a little bit more life than its opponent, and if it was ahead it would immediately start spawning threads, until the play server couldn't handle it anymore and crashed -- Winning by default.

<comment><USER24> I had a similar kind of assignment, using a java system called robocode. I ended up writing a system that could track a tank moving in a static arc, while moving itself, which worked surprisingly well.

</comment></comment></comment><comment><USER25> Then they taught it to make paperclips, and ended up with one of these:

<http://wiki.lesswrong.com/wiki/Paperclip_maximizer>

<comment><USER26> Until it finds a glitch in the matrix that allows it to pause real life.

<comment><USER27> Bruteforcing all states of NES game could result in finding vulnerability in NES emulator and then to fill memory of emulator with FFs via changing settings it could make mess from accessible file system or, some life spans of universe later, find vulnerabilities in OS, hardware or connected network.

</comment></comment></comment><comment><USER28> "This game is mostly a go to the right and jump and throw hammers at birds..." Classic delivery. I love this guy.

<comment><USER7> He made me laugh repeatedly.

</comment></comment><comment><USER29> If your numbers are going up, it means you are having more fun!

<http://radgeek.com/gt/2006/04/28/antieconometrix_comix/>

It's too bad that game that need more lookahead - Tetris, etc, are not amenable to this approach.

<comment><USER30> It sounds to me like it's basically how deterministic a game is that determines whether this works. For a Tetris with a defined order that the pieces appear in, I bet this algorithm could do pretty well.

<comment><USER4> For the purposes of this AI player, all NES games are fully deterministic. Even what hardware the NES had that could be used for random number generation is under the control of the emulator and being run deterministically. There's no "random" in the usual sense here.

</comment></comment></comment><comment><USER31> Pardon me if I'm really ignorant of the AI field here, but doesn't this look like the beginning of more general artificial intelligence? The organic feel of some of these moves is almost scary to me.

<comment><USER32> Keep in mind that it's using time travel to do those moves. In the real world time travel is not currently available.

<comment><USER8> When a baseball player swings a bat, in anticipation of the ball arriving just in time to get knocked out of the park, do you consider that time travel?

Is the baseball player's anticipation of the future really all that different from what this program is doing?

<comment><USER33> Yes, it's incredibly different! A huge problem in AI is internally modelling the outside world. This completely sidesteps that.

<comment><USER8> Maybe, but that doesn't really have anything to do with the "time travel" question.

<comment><USER33> Of course it does. Models are useful because they have predictive power. If you have time travel, you don't need to predict anything.

</comment></comment></comment></comment></comment></comment><comment><USER34> Related: genetic algorithms to play video games. I can't find the exact one I read about before, which was for Super Mario Bros., but searching for "mario genetic algorithm" leads to a number of papers, videos, &c.

<comment><USER35> There are a[1] couple[2] on YouTube.

[1] <http://www.youtube.com/watch?v=qYluZRwrw9w>

[2] <http://www.youtube.com/watch?v=DlkMs4ZHHr8>

</comment></comment><comment><USER36> I love the fact that a newspaper can still publish this without fear of losing viewers. It's like eating at a restaurant that everyone qualifies for dog food but... well...we go anyway :)

</comment><comment><USER37> Very funny video and worth watching.

But it's not even close to beating NES Games. I'm not a expert in AI but I'm not sure it actually achieves anything.

I'd consider it more an art project than a computer science project.

<comment><USER38> You must not be very fun at parties.

<comment><USER39> Depends on what sort of parties you like.

</comment></comment></comment><comment><USER40> Using A* does a much better job: <http://www.youtube.com/watch?v=DlkMs4ZHHr8>

Look at that AI play. It's godly.

<comment><USER41> The paper uses an approach general enough for any game on the NES, which is what makes it exceptional. The humor is killer, too.

</comment></comment><comment><USER42> The ending is very poetic in a way.

</comment><comment><USER43> More authors should make videos like. Well done!

</comment><comment><USER44> I wonder how this would handle an NES golf game.

<comment><USER45> In "NES Open", you earned money depending on how you placed. So, given long enough jumps back in time, there is a way to track an increasing score.

Either way though, I think the results would be _sub-par_.

<comment><USER22> slowclap.gif

</comment></comment></comment><comment><USER46> The only winning move... is not to play.

</comment><comment><USER47> Uninformed speculative question here: could the algorithm be improved with some sort of momentum term in the input selection?

It seems to succeed with move-to-the-right (position counter) but fall into what looks like Brownian motion on Pac-Man. It seems to me that putting momentum into its strategy (and changing when the objective function declined) might reduce the implicit branching tree.

What it simulates, then, is the tendency for people to fall into "a groove" and depart from it when their objective function ceases increasing.

<comment><USER8> I'd really like to see a fuller analysis of what Pac-Man was doing there. As I understand the algorithm, it should have seen into the future where the dot gets eaten, and not turned back.

But maybe the program failed to discover the bytes which hold the score, and so it didn't think eating dots was a particular notable activity.

<comment><USER48> Maybe it gets distracted increasing the pac-scent? There's certainly a lot more of that around in memory

</comment></comment></comment><comment><USER49> i hope i live until the day when robots can beat games without any prior knowledge of the game logic,well actually it would be quite scary

<comment><USER50> Scary indeed. Those robots might be very good at ... Thermonuclear War.

</comment></comment><comment><USER51> ... sooo, that's not really a great application of a GA. Perhaps not even a great implementation.

Akin to making things out of Legos at best. (ie: "because!")

<comment><USER52> It's not an application of a GA at all. Before dismissing something, it's best to understand it.

</comment></comment><comment><USER53> Considering there are bots to beat you at Call Of Duty, and Quake, this is not such a feat.

I can't find a reference but I recall an Emulator for NES that used to be able to be player 2 for something like 40 NES games.

<comment><USER54> I think you missed the point somewhat. Those bots were coded just for those games, with human-made models and strategies adapted to them.

This bot, on the other hand, understands nothing about the games themselves besides the input keys and the score number(s). It's playing blind.

<comment><USER53> Having written real AI's this aint one.

4 directions and two buttons. You could point a crappy machine learning algo at it, and it would figure it out. That is far fewer variables to manipulate than what a Quake bot has to deal with.

I would bet money I could zap a pigeon every time it died in mario and it would learn to be a master in 12 hours. It won't master CoD anytime soon.

<comment><USER15> How would it figure out what it means to be "winning"? It might be possible, but would require using OCR to read the 'score' (and guessing as what is meant by the score) and would also need some way to determine if the goal is to "go to the right", etc. (also possible). Doing this would be interesting and more practical in that it could work with games where you do not have access to the memory, but seems like it would require more work in interpreting how the game's state has changed and wouldn't allow going back in time.

A Quake bot is easier to develop because it is written for a specific game.

I accept that bet for training a pigeon to play SMB :), although the scenario you described isn't comparable (it is only one game and you would be giving the pigeon extra feedback about how to play it. It still seems hard and I think it would be notable if you achieved it.)

<comment><USER53> This AI has access to all of the ram of the game.

There are Guitar Hero Bots taht "OCR" (your words) the screen to play the guitar. Not such a hard trick to read a score or see a turtle. (you know we have self driving cars right?)

<comment><USER15> I think trying to understand what is going on in a game by looking at the screen would be more challenging than trying to understand by looking at the game's memory if you want to write a bot that can play any generic game.

The examples you gave are each specific to particular domains.

This whole topic reminds me of how it is much easier to develop natural language processing for use in a particular domain compared to generically.

<comment><USER53> I write "generic" Natural language processing for a living.

Also "nintendo" is a particular domain. When you only have a "language" of 8 directions, A, and B, and only time to deal with in response to a screen that side scrolls in only one direction the programming is easy.

A chess engine has more potential decisions for a bishop than this has for a given move. And unlike the the NES, the chess engine has to adjust for changes in the behavior. Given the same input the NES would make the same choices. You can macro through most the games.

<comment><USER55> I think 2 things need to be emphasised.

1\. This was a paper submitted for a joke conference. It is in no way a giant leap in AI. It is something that some nerds find amusing. Like an anti-Rube Goldberg machine. It is trying to accomplish something quite complex using a ridiculously stupid approach.

2\. Its stupid because it is looking at the memory state as just a list of numbers that change during the gameplay. It has no knowledge of the actual game. It doesn't parse the memory to figure out game state or anything. It doesn't even have any generic idea of what games involve. It figures out "oo, the number that starts at location 243 goes up in the training data. I'll mash buttons to try to make memory location 243 go up".</comment></comment></comment></comment></comment></comment></comment></comment>


Building a global, free and open IoT network - <AUTHOR> http://thethingsnetwork.org <comment><USER2> Does this provide a bare IP connection or is it just for MQTT channels back to your servers? I can't tell if that's "the" method of communication or just a helpful thing that you're offering.

Basically, is this something that I would be able to use directly with my company's CoAP APIs?

<comment><USER3> The protocol speaks LoRaWAN, which isn't IP. The data will get sent via a distributed network, over IP (using MQTT), to a server of your choice. This application server (run by you or someone else) can then store the data, have a REST API endpoint, MQTT channel, or whatever service that runs there.

</comment></comment><comment><USER4> Thanks for the post! We are very happy how this is progressing and for all the contribution around the world.

</comment><comment><USER5> Anyone know what frequency bands these are being deployed in in the US? I am assuming they using the 902-928Mhz ISM license free band.

Licensed frequencies would make this significantly more involved to deploy in the US.

<comment><USER6> 915 MHz

</comment></comment><comment><USER7> Support The Things Network. They are not only supplying easy to activate hardware, they are hard at work at an excellent architecture ([http://forum.thethingsnetwork.org/t/request-for-comments- net...](http://forum.thethingsnetwork.org/t/request-for-comments-network- architecture/287)) and a clean, easy to use integration framework.

<comment><USER8> it would be so cool to just fiddle with IoT sensors without worrying about a nearby wifi hotspot with access. Just using the Things network as a free and open road is a beautiful idea.

<comment><USER9> And I have gotten my base IoT node down to about 2.50$. How?

Arduino Nano ($1.80) nRF24L01+ (0.63$)

Both from Aliexpress. Combine it with MySensors library and off you go.

For secure connections, use the USB-serial gateway, change the default channel, turn on encryption as well as signing support.

I use Node-red to get the data and do stuff with it.

</comment></comment></comment><comment><USER10> Two questions: 1) are there technical restrictions for using this mesh network with remote aerial sensors, i.e. does it hurt badly when nodes move? 2) how well would it perform indoors in manufacturing plants? I'm thinking of low- cost adhoc industrial IoT prototyping.

<comment><USER11> According to the spec [1] it's for both mobile and fixed devices:

"LoRaWAN™ network protocol which is optimized for battery- powered end-devices that may be either mobile or mounted at a fixed location. "

[1] [http://www.lora- alliance.org/portals/0/specs/LoRaWAN%20Speci...](http://www.lora- alliance.org/portals/0/specs/LoRaWAN%20Specification%201R0.pdf)

</comment></comment><comment><USER6> Awesome effort! We're following Amsterdam's example in Zurich and building a TTN network over here. The initial tests went great and we're now preparing to deploy more gateways real soon!

</comment><comment><USER12> Let's cover the US together! We don't have to wait on big corp's to do it, let's make it ourselves!

</comment><comment><USER13> How does this compare to the SIGFOX network?

<comment><USER14> SIGFOX has certain limits (outside of theoretical and practical bandwidth restrictions) placed on it. radio-electronics.com ([http://www.radio- electronics.com/info/wireless/sigfox/basics...](http://www.radio- electronics.com/info/wireless/sigfox/basics-tutorial.php)) states up to 140 messages of 12 bytes per object per day, with a throughput of up to 100 bytes per second.

The Things network, on the other hand, seems to supply its services openly and freely without limits, using the LoRaWan spec. Semtech ([http://www.semtech.com/wireless-rf/lora/LoRa- FAQs.pdf](http://www.semtech.com/wireless-rf/lora/LoRa-FAQs.pdf)) says it provides between 0.3 and 11kbps of bandwidth, so in theory your speeds can be anywhere from 3x to 111x higher.

</comment></comment><comment><USER15> The range of these things is inmense, the possiblities endless: I love how you guys bring this technology to everyone!

<comment><USER4> Thanks Thomas!

</comment></comment><comment><USER16> Great Job! Singapore and Malaysia will TTN soon also, the things.. are in motion.

<comment><USER4> Awesome!

</comment></comment><comment><USER17> How can we get this in Victoria, BC, Canada? Anybody want to team up?

</comment><comment><USER18> Groningen pledged a city wide network within 12h. You guys rock!

<comment><USER8> the whole city? How cool is that! #dreamingofgoingbacktogroningen</comment></comment>


Ask HN: Non-native English speakers, what are your biggest struggles at work? - <AUTHOR> I am interested in learning what kind of difficulties non-native English speakers, like myself, face when working on English speaking environments. <comment> kalium-xyz Though not language related: coworkers who don't understand that formats for addresses differ depending on the country. It can be quite hard to understand the way to read an address from a foreign country.

Also some confusion on when the week (calendar, not work week) ends (some countries end the week at Saturday rather than Sunday).</comment>


The Day the Pirates Came - <AUTHOR> https://www.bbc.com/news/world-asia-52295222 <comment><USER3> Super interesting and well written story. The question I'm left with is more around the illegal oil trade. Who buys that oil, how do negotiations work, pricing established, etc.

<comment><USER4> It is principally a profit region of Royal Dutch Shell, of course, through a conglomeration of subsidiaries and shell companies (NNPC, TEPNG, and NAOC) designed to prevent the world from knowing the truth about the wealth being extracted from the Nigerian people.

The Dutch oligarchs, as well as their Royal family, are the ultimate beneficiaries of the turmoil in that region. They finance MEND, who showed up in 2006, 7 years after Royal Dutch was kicked out. TEXACO, Howard Energy - <USER2> the standard Western blood oil players are waiting in line for their share. (Blood oil is a Western game. The oil won't be nationalised, those who rule Africa from afar will never allow this to happen.)

There are also, of course, second-level groups perpetuating the violence to reap profits:

"While Niger Delta youth may handle the local tapping and loading, international players from Eastern Europe, Russia, Australia, Lebanon, the Netherlands, and France all play roles in financing, transporting, and laundering the money associated with blood oil. One money trail followed a path from Senegal and Côte d'Ivoire through French banks and French credit agencies to Syria and Lebanon. It also now appears that Nigerian Lebanese (those of Lebanese descent, born or naturalized in Nigeria) are heavily involved in the business, especially those with good political connections. Similarly, many top Nigerian politicians and military officers, both serving and retired, are said by internal sources, such as the army chief of staff, to be actively involved in the large-scale bunkering business."

[https://www.usip.org/sites/default/files/blood_oil_nigerdelt...](https://www.usip.org/sites/default/files/blood_oil_nigerdelta.pdf)

</comment></comment><comment><USER5> Sometimes it feels like a blessing to live in a country without natural resources worth killing for.

<comment><USER6> You don't even need to have natural resources.

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

<comment><USER7> 4.5 long hours for the "but America" comment to appear. Rookie numbers.</comment></comment></comment>


Online demo extracting 3D from a series of 2D images - <AUTHOR> http://3dsee.net/Main.aspx <comment><USER2> Do you really need "complete access to your computer" to do 3D in Java? That's what the viewer applet is requesting according to the warning I get, and that sounds a bit over the top to me.

<comment><USER3> Maybe opengl calls?

<comment><USER2> Possibly, but that's something that shouldn't require "complete" access to the OS. Maybe it does, hence my question :)

<comment><USER4> I am fairly certain that does not require complete access but applet security is a pain in the ass and I am sure few people know how it really works. They probably opted for full permissions over granular permissions because it is easier.</comment></comment></comment></comment>


The $29B battle to own how America sleeps is heating up - <AUTHOR> https://www.fastcompany.com/90216464/ <comment><AUTHOR> Slight self promotion: We are a technology start up and we are looking for contacts in the mattress industry. Fell free do contact me: firstname.lastname@example.com</comment>


Asciinema – Record and share your terminal sessions - <AUTHOR> https://asciinema.org/ <comment><USER2> I never knew this existed. I'm in the process of documenting some homegrown CLI tools for non-unix people at work, and this is gold!</comment>


Antimosquito iPhone App - <AUTHOR> http://www.swiss-miss.com/2011/07/antimosquito-fumigator.html

<comment><USER2> The system works but is not really true that humans can not hear it, especially teenagers can hear and it's really annoying and can be painful, have existed for years about gadgets that make this sound and can be very annoying, I remember that even came into use in places where they did not want teenagers partying in the night and were legally prohibited such use</comment>


"Removal of powerpc as a release architecture" - <AUTHOR> https://lists.debian.org/debian-devel-announce/2016/10/msg00008.html <comment><USER2> Sad, but a day everyone knew would come. I totally understand the lack of support for a dead architecture. It's not like you can just keep throwing software at these machines and run them fine anyway.

I have a 2003-04 era Powerbook with Ubuntu on it. It runs 10.04 just fine, but any newer and it's pretty damn slow. Basically the only thing I can do with it now is text based stuff, and not much of it. Some Python, bash C++ etc. Can't even really browse the web, because the newer versions of any web browser won't run/compile.

Since I can do all of those same things on my current laptop just fine there's no motivation to use the PPC mac other than nostalgia. Imagine how the folks feel trying to support it now?

<comment><USER3> It frustrates me that computers become obsolete this way. We've generated an awful lot of waste and not a whole lot of progress. Everything I do now I could do ten years ago, it's just "prettier" now. I'd go back to one of these old machines in an instant if it didn't mean that reading articles on the web would be so painful.

<comment><USER4> This comment reminds me of a story I heard years, years ago. I was living in central Asia, in one of the post-Soviet countries. (As an aside, I met quite a few people there who much preferred life under Soviet rule. Sometimes at parties in the countryside they'd even start singing rousing choruses of the soviet anthem!)

Anyway, the apocryphal story goes, Krushchev is visiting a Western washing machine factory. He sees all the different models coming off the line, this one has two agigtators, that one has three speeds, whatever. He sees the churn of factory equipment. All that hustle and bustle to try and sell more washing machines.

He laments, "Oh, you capitalists, you're _so_ inefficient. Look at how much time and effort you waste on with all this competition! We soviets made one washing machine, and it works!"

<comment><USER5> It's a little deceptive to label these kinds of sentiments as contrary to the premise of innovation.

Experiments, by nature, require expendable resources, but an finished appliance intended for a consumer, with no end-user-servicable internals is not the sort of thing you want to have spewing garbage in all directions.

The reality though, is that we're all being railroaded down strict paths of planned obsolesence that are integrated into business models from day one.

Yours and my waste should not be interpretted as an unforced error. It's carefully planned, with the intent to fund more plannings sessions to forecast more waste.

...at least down among these lower eschelons we inhabit (speaking for myself, so as not to make assumptions about who reads this), and then there are those who ride above it all and skim from the fruits of our obesity.

<comment><USER6> There are side channels for places like apartment complexes that want a much longer device lifespan and are willing to pay for it. Planned obsolesce is much more common on the 'mass market' channels than the industrial channels.

You really can still buy refrigerators that will last 30 years. They just don't have built in ice makers etc.

PS: The 50-200% premium may seem steep, but if it lasts 5x as long then you more than break even.

<comment><USER7> Where can I buy these 30 year refrigerators?

<comment><USER6> As a consumer a Sub Zero fridge tends to last over 20 years on average. And significantly longer than that if you clean the condenser annually.

Past that, Arctic Air for example has commercial refrigerators which will last 30+ years if you do some occasional repairs. Though, they really don't look like home units.

</comment></comment></comment></comment></comment></comment></comment><comment><USER8> Note that "powerpc" is the 32-bit PowerPC, if I'm not mistaken.

ppc64el (64-bit little-endian PowerPC) is listed as a release architecture.

<comment><AUTHOR> The port covered both 32 and 64 bit chips. The specific 64 bit little endian support (ie, your old iBook) was broken out into the ppc64el in either Squeeze or Jessie.

<comment><USER9> Apple PPC[64] devices were all big endian. Little-endian mode (ppc64le) was introduced on POWER8 circa 2013.

<comment><AUTHOR> The chip itself is ambidextrous or whatever the word is.

<comment><USER9> It depends on what you mean; the PowerPC 970 (G5) did not support little endian mode at all. Earlier PowerPC devices (dating back to the PowerPC 601 IIRC) do in fact support runtime switching of endianness, although they were all 32-bit. PowerPC 64 LE is only supported on POWER8 (and apparently, per other commenters, requires hardware support although as a Mac developer I stopped paying attention after the 970 for some reason :)

I think it's probably fair to say all the Apple devices that shipped were big endian as the OS and firmware were, and while in theory the 32-bit machines could operate in little-endian mode I don't know of any distributions that actually did so, and 970 didn't support it.

<comment><USER10> Matrox (yes, the graphics card company) sold a PCI board with several PowerPC "G4" chips that ran little-endian Linux. They posted a smallish kernel patch for this.

MC/OS and Windows NT 4.0 also ran little-endian on PowerPC.

The hardware support was simple: swap all 8 byte lanes for every memory access. It only mattered when MMIO or DMA was involved, so a software-only alternative was to have the OS do that -- but disk access via DMA would make the software solution impractical.

</comment></comment></comment></comment></comment></comment><comment><USER11> This is really sad. I was really hoping the Talos would get funded:

[https://www.crowdsupply.com/raptor-computing- systems/talos-s...](https://www.crowdsupply.com/raptor-computing- systems/talos-secure-workstation)

..but it looks pretty far from its goal. :( Still it's the best alternative architecture that's free of binary blobs, that isn't ARM. If we do see open ppc hardware, this will mean one less potential OS we can use.

EDIT: it looks like they're just dropping older 32-bit PPC per the other comments. So, this doesn't seem as big a deal really.

<comment><USER12> It's difficult to justify spending $7k for a motherboard and CPU that only sometimes matches the performance of an Intel equivalent at $500. Only the most security-sensitive applications could justify that price. They need an investor with deep pockets and no compromising motives.

<comment><USER13> > It's difficult to justify spending $7k for a motherboard and CPU

$7,500 is for the complete workstation. The mainboard is $4,100:

> [https://www.crowdsupply.com/raptor-computing- > systems/talos-s...](https://www.crowdsupply.com/raptor-computing- > systems/talos-secure-workstation)

<comment><USER14> And you need to add at least $1100-$3000 for the CPU, so it's still >=$5200. Note that your price for the "complete workstation" does not include a CPU either.

</comment></comment></comment></comment><comment><USER15> Meanwhile, I'm continually amazed that s390x [1] remains supported. I've never seen such a system in the wild.

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

<comment><USER16> I took a university course that was specifically about IBM midrange machines. The instructor had one on his desk. I remember that the whole architecture was based around virtual machines. One assignment involved downloading a 5250 emulator and logging into some IBM mainframe to leave a message. I even got a t-shirt for that.

Unfortunately, the instructor quit about a month into the course. Just one day, we came into the room and some higher up faculty were there instead. I don't know for sure what happened, but his Linked-in suggested that he was hired by the government of Egypt. (Mind you, this was 2009) It must have been very important.

<comment><USER17> That is IBM i, aka OS/400, a completely different beast than s390. It's one of the most underappreciated and misunderstood examples of systems software in the industry. It's survived four distinct CPU changes of the same magnitude as Apple m68k->ppc->ppc64->ix32->ix64, except retaining full compatibility back to the original (and even further back to System/3x). Because everything above the analogue of the syscall layer is machine independent code, you get new benefits with even minor hardware ISA upgrades for existing code without rebuilding. This is all basically "free" for the user without any thought or downside. IBM was also doing ahead of time Java compilation to MI for ~15 years. IIRC this was one of the fastest platforms for JVM apps for many years.

The closest equivalent outside OS/400 would be like using LLVM IR for the entire system. But the memory model is also very elegant, the Single Level Store allows for storage tiering without the kind of block layer hiding that most solutions use.. closest equivalent is ZFS with a L2ARC in the POSIX world.

The lessons learned from the machine dependent part of IBM i were used to build the pHyp hypervisor in POWER4+. This is a firmware level microkernel and very interesting in its own right.

This isn't to say you should go out and port everything to IBM i, just that it should be studied by any serious OS developer and academic. While there is a good book on the design by Frank Soltis, the chief architect, it does not go into anywhere near the depth that UNIX design books did even when covering the proprietary versions. I wish I could learn a lot more about it.

<comment><USER18> It's such a damn shame that IBM makes all of this stuff utterly inaccessible to the developer, hobbyist, and academic crowds.

In the past few years I've taken an interest in big-iron systems, and I've recently started spending time with OpenVMS in preparation for release of the x64 port. I spent a lot of time digging into System i, and z/OS, but my efforts were constantly frustrated by the inability to get my hands on real software and/or hardware, or even paid time on a machine.

Shoutout for the OpenVMS hobbyist program. Anyone interested in obscure commercial OS's with serious pedigree should give it a look. HPE's OpenVMS documentation portal is well laid out and straightforward - all the information is there.

<comment><USER19> There is [http://pub400.com](http://pub400.com) which'll give you free terminal access onto an IBM iSeries

</comment></comment></comment></comment></comment><comment><USER20> I have an old PowerBook (from about 2005, not long before Apple's intel switch) that still runs fine, after replacing RAM a couple times. I use it as my back-up computer at the office to this day, sometimes bring it to the coffee shop to outhip the hipsters. It's been running the Debian PPC port for many years without much trouble.

Of course this does not come as a big surprise; I'll just keep running the most recent version until the hard drive dies and my current laptop becomes the back-up.

Are there any distros still standing with PPC support? I used to run Ubuntu, but it was dropped years ago.

<comment><USER21> Its not linux, but NetBSD still has its macppc port. And Gentoo.

<comment><USER22> Looks like Yellowdog Linux is discontinued, but at the time it was great: [http://www.fixstars.com/en/technologies/linux/](http://www.fixstars.com/en/technologies/linux/)

One of the best features of that distribution was none of the standard pre- compiled root-kits would run on it, plus all the buffer-overflow attacks had to be customized for PowerPC, something few script kiddies had the capability of doing. It made for a surprisingly resilient system at the time.

</comment></comment></comment><comment><USER23> While it may be petty to say, I think it is accurate to point out that this sort of news tends to lead people to focus on the "winning" commodity architectures, in this case x64 and ARM, and minimize the use of other architectures.

If I were starting a business today, you'd have to give me free hardware that used POWER or SPARC cpu in order to persuade me to use it. The last thing I want is to have to switch hardware platforms; and thus x64 and ARM are the safe choices.

<comment><USER24> You've kind of got the cart before the horse. People already minimize the use of PowerPC, and that's why Debian is dropping it.

</comment></comment><comment><USER25> Is there any popular hardware that is PowerPC?

<comment><USER26> Not popular but all "modern" hardware for AmigaOS is PowerPc based.

[http://www.amigaos.net/content/72/supported- hardware](http://www.amigaos.net/content/72/supported-hardware)

[http://www.acube-systems.biz/index.php?page=hardware](http://www.acube- systems.biz/index.php?page=hardware)

<comment><USER27> Those are 64-bit ppc CPUs, not the 32-bit that ppc references.

<comment><USER26> None of them are POWER8, the minimum to run Debian ppc64el[1]

[1] [https://wiki.debian.org/ppc64el#Required_Hardware](https://wiki.debian.org/ppc64el#Required_Hardware)

</comment></comment></comment></comment><comment><USER28> most of this thread is concerned with the desktop. but powerpc is widely used in the automotive systems. Those systems are running either some form of Linux, an RTOS or a bareboard exec. The modern powerpc SOC's are available in very wide temperature ranges (-40..+125) which makes them attractive for automotive. The QorIQ ppc's are used in networking also.

<comment><USER29> The Linux kernel still has support. Running Debian is no longer an option, but I doubt many embedded systems were doing that anyway. Most probably were running some Yocto image from the SoC vendor. So it just means cross compiling from source now.

</comment></comment><comment><USER30> crap.

Since jessie, I could not maintain my old Sparc V100 server.

Now it's my PowerBook G3 Pismo :(

(to be true, it wasn't very usable anymore, 45 seconds 100% CPU to load the main gmail page just to give an idea).

</comment><comment><USER31> More detail on why would have been interesting. Especially with other lesser known architectures still supported.

<comment><USER32> No (credible) volunteers to manage the port, it seems: [http://www.mail- email@example.com/...](http://www.mail- email@example.com/msg65880.html)

<comment><USER33> I didn't go look but that was going to be my guess. Since Debian is volunteer- ran, each architecture needs people to manage it, as well as having adequate hardware to test/build on.

</comment></comment></comment><comment><USER34> Excellent name. :-)

</comment><comment><USER35> We've updated the title from "Debian drops support for PowerPC", which breaks the guidelines by being editorialized.

<comment><USER36> It may well have been, but the title as it stands now is useless. I was forced to click through and read all the comments to find out what this was about.

<comment><USER35> The title "Release Architectures for Debian 9 'Stretch'" is precisely accurate; it's what the linked article _is_ and was titled that way by the author for a reason. On the other hand, because the article states that the removal of PowerPC is the only change from Jessie we've reverted the title to something that expresses this.</comment></comment></comment>


Man vs. Machine; Wall Street cuts trading staff for algorithms - <AUTHOR> http://www.nypost.com/p/news/business/man_vs_machine_kcKBB0HkdpQr4jtAUprbIK

<comment><USER2> Never underestimate the power pure mathematics applied, and know the history of dangerous consequences when misapplied. For example, LTCM's Black-Scholes' Black Swan catastrophe.

<comment><USER3> They know all this, and this bad behavior will not be corrected as long as moral hazard exists.

<comment><USER4> I think the word you're looking for is perhaps "curbed", not "corrected". Even without moral hazard big financial institutions are perfectly capable of screwing up big time. E.g. a few days ago I looked up the decline and fall of the Medici Bank ([http://en.wikipedia.org/wiki/Medici_Bank#Decline](http://en.wikipedia.org/wiki/Medici_Bank#Decline)) back in the 15th Century, and there are plenty of recent examples.

<comment><USER2> That is an interesting wikip link I'd never think to branch on, say, in my past personal history interest of Florentine family rivalry. If you are particularly versed of European banking, would you know of what banks have had a long run, or the most durable? I understand Baring's had been around awhile, until their recent demise.

BTW, I read once, the Beretta family, Brescia, Italy, has been making guns, privately owned, for some 500 years, perhaps the most enduring privately held company surviving today.

<comment><USER4> Afraid I'm not well versed in European banking history, just the highest of highlights, e.g. I know the names Medici and Rothschild, of the Credit-Anstalt failure and various of the current names. (This is a very post-WWI American attitude per [http://www.amazon.com/gp/product/0375412301/](http://www.amazon.com/gp/product/0375412301/))

But I _am_ something of a domain expert on firearms, and yes, the Beretta family has been privately making guns since 1526 ([http://en.wikipedia.org/wiki/Beretta](http://en.wikipedia.org/wiki/Beretta)):

" _The Beretta company was established in 1526, when gunsmith Maestro Bartolomeo Beretta of Gardone Val Trompia (Brescia, Lombardy, Italy) was paid 296 ducats for 185 arquebus barrels by the Arsenal of Venice. The bills of sale for the order of those barrels are in the firm 's archive._"

And I know their post-WWII quality is very good, my father is big on them for smaller stuff since he'd left handed and they're big on being adjustable for lefties, even ejection direction in carbines (!). They got the contract for the US military's "new" handgun---well, as of 1985, I carry the previous 1911 design since it fits my hands _perfectly_ \---and of course they set up production in the US.

I bring this up because they made the mistake of doing that in Maryland, prior to this year perhaps the most tolerable of the viciously anti-gun states in the US. Once it started going over the top post-Newtown, one of the family members came over, talked to the governor, etc., to no avail, and now they're expanding outside of the state and eventually moving production. They of course took it as among other things a personal insult, and no doubt deeply understand the vicissitudes of politics.</comment></comment></comment></comment></comment>


How to avoid dying in a car crash - <AUTHOR> http://lesswrong.com/lw/awm/how_to_avoid_dying_in_a_car_crash/ <comment><USER2> > The most dangerous month, it turns out, is August, and Saturday the most > dangerous day, according to the National Highway Traffic Safety > Administration

Saturday and Friday night at those times are dangerous where I'm at because of end-of-summer parties and drinking. Lots of drinking.

> "overconfidence appears to be a large factor in peoples' thinking about > traffic safety"

This will never change. As long as we have overconfident drivers, we will have accidents. Confidence = "I don't need to double-check". Sadly, that same overconfidence is why you can't convince anyone to NOT be overconfident. It's a self-confirming cycle, and people only become more careful after the accident because, as every overconfident driver says, "It'll never happen to me." (getting in an accident, that is)</comment>


Creational OOP Design Patterins in TypeScript - <AUTHOR> https://replete.nu/pith/creational-object-oriented-design-patterns-in-typescript/ <comment><USER2> lol, Singleton as first example, is this an elaborate troll?</comment>