Cogs bad - <AUTHOR> http://williamedwardscoder.tumblr.com/post/18065079081/cogs-bad <comment><USER3> Maybe people succumb to the hype. Maybe they want the latest shiny running their own shiny new thing. I'm sure these things contribute greatly.

But I see another aspect to this whole "We Use Shiny Cogs" movement: high- level vs. low-level. As we make tools that abstract us away from the metal, we are able to spend less time thinking about the electrons flowing across silicon and more time thinking about building something John Q. Public will pay for.

We architect higher and higher abstractions for exactly this reason. And it comes with a price: at some point you stop running things as efficiently as possible and there's waste. If we were all studied CS students and could write kernels and compilers from scratch, we might spend five years building a very tight, efficient stack for Twitter that could run on a single box (maybe with a hot failover). But we're not. We're a collection of humans with differing levels of understanding and will power, many of whom just want to Get Shit Done and stop thinking about kernel task queues.

So lets turn his "rich man's problem" around a bit: you build your idea on top of a stack that you understand and keeps you happy, and when you bring in the capital (through revenue or investment - whatever) you put money into deeper, lower-level engineering. Until then, build your idea the way you know how.

<comment><USER4> _"As we make tools that abstract us away from the metal, we are able to spend less time thinking about the electrons flowing across silicon and more time thinking about building something John Q. Public will pay for."_

That makes it sound like there's a complete dichotomy here. It's not like the mailinator guys are doing assembly whereas the rest of the startup crowd is doing Prolog AI. Never mind that I doubt that most backend programmers employed are using the time saved on improving the sheer monetization output of the company (mileage obviously varies for single-person shops).

I do think you hit the nail on your head with your final paragraph. Quite often it's not that the people programming this _choose_ to pick the cogs, quite often they don't _know_ any other way. In which case this isn't really a decision. But it's a sad trend in my opinion. Remember the old saying "Nobody ever got fired for choosing IBM"? I think the level where this kind of thinking is applied has dropped from non-technical upper management to some actual builders. Smart business decision - maybe. But I do think that a lot of us here aren't just in it for the money.

<comment><USER5> The new people are not in it to perfect their engineering craftsmanship. Overall product craftsmanship maybe, but then half their attention is taken up by visual/UX design, they have less time for beautiful plumbing.

But at the same time engineer craftsmen can specialize in making better cogs. That would be the ideal, better cogs like Stripe, Heroku, Redis, DynamoDB, whatever. Someday most will stop thinking about those problems just as we stopped thinking about design patterns of making procedure calls in assemblers.

<comment><USER6> In your story "better cogs" sound like "more cowbell". It's still a fundamental decision which will not go away: do you solve a problem in process or do you communicate with anything external: Redis vs. HasMap. It's not comparable to levels in programming languages.

<comment><USER5> What about a programming language that integrates fancy cogs so they're conceptually in process? Do I want to know the difference between sorting in the native data-structure and Redis? Hopefully not, the language/compiler could make that call.

Programmer could specify how much data he's sorting, how fast he needs it sorted, how much data he'll get after each sort and the language will decide which cog to use for best performance. You don't need to know what Redis, Riak, or native data-structures are.

<comment><USER6> Hmmm ... aren't _these_ cogs called libraries?

But the question was: can I afford to go through a tcp socket (and that's a long way, possibly even to another machine) or not. A language cannot cover this up.

<comment><USER5> Yes they're probably libraries, but in the language of the future that covers everything up you wouldn't know such distinctions.

Why can't a lib/lang cover it up? You tell it how much data will be stored and transferred. It will benchmark various approaches, having separate DB nodes or not, determine how many users each setup can support. The developer would need to be aware that 5000 users can fit into a $10 per month box. When he wants more users, he gets more boxes. If he wants more users per box he must cut expensive features.

Amazon DynamoDB does something along those lines by asking the dev to specify how much data to store and how many transfers to expect. The details of setting up nodes, how many nodes, how they're sharded, hashed, are hidden.

</comment></comment></comment></comment></comment></comment></comment><comment><USER7> This article, and the Hickey talk to a greater extent, present a coherent but one-sided argument about elevating simplicity and understanding above human concerns in software engineering.

It's true that, as a programmer, you should strive for simple, "correct by inspection" code when possible. And the better a programmer you are, the more you will see and take opportunities to write a bit of code instead of roping in a third-party library, to use a small library instead of a big library, or use a library instead of another process, thus avoiding large swaths of complexity, the bane of software development. On the flip side, poor engineers may make large errors of judgment in this area.

However, a bias against powerful, off-the-shelf tools or a disdain for the "familiar" over the "objectively simpler" is no better. The line between a one-man (or few-man) project and a bigger project is where this really starts to matter. News flash: You can't get that "my code feels correct" feeling (the one that's supposed to substitute for a formal proof your entire system works) when other people are writing it. When putting together a team, using technologies that are "familiar" doesn't seem so intellectually lazy -- and many popular technologies are actually very understandable and well- engineered. Finally, I'm taken by end-to-end testing and Eric Ries's "immune system" metaphor as a way to ensure correctness of a complicated system in practice.

If you're making something big, you might have to put down the microscope. If you're making a tapestry, you need to have multiple threads entwined and stay cool.

<comment><AUTHOR> Nicely put.

Do you think `new ConcurrentHashSplayTree<String,int>()` is slower and less space efficient than roping in a Redis server as the LRU?

Didn't think so. That was more my rant, though.

</comment></comment><comment><USER8> I have experienced this dilemma in a different domain: machine learning. You can either go the Hadoop way and commit to simpler algorithms that can be run in distributed manner or you can keep pushing the single machine more and more by use of ever more clever algorithms. Unfortunately, it is hardly ever possible to follow the route of push-single-machine-to-max -> thorw-more- machines-in. The distributed way and shared memory way of doing things often differ in fundamental ways.

Going with big data tool chains from the start is often a overkill for small experiments. But once you outgrow one machine, the pain of undoing all the nice (algorithmic) tricks is also quite severe.

Perhaps it is time to accept that we now produce data at a rate that distributed is going to be the way to process it. But this also means that some of the techniques available for scaling to larger data sets may need to be given up.

<comment><USER9> I'm hoping the <http://graphlab.org/> approach may help bridge the gap a bit here...

</comment></comment><comment><USER10> Developers (myself included) worry too much about future unlikely pain and suffering, especially the degree of said suffering. Maybe you spend a few weeks here and there rewriting things. Big Deal.

Scalability and performance is complicated. Unless you KNOW your product will have a big splash, premature optimization will kill your productivity. And you will get it wrong. You will get the implementation wrong. You will optimize the wrong things and not really understand your bottlenecks. Especially if you've never scaled anything before and haven't been bitten twice by all the compromises you have to make.

Distributed systems are hard. Multi-threading is hard. Sharding is hard. CAP is a bitch. If you can scale vertically, do it. Avoid the demons of distributed work until you require them.

Most of the services/apps we build today would do just fine with setups like Mailinator or _gasp_ ACID-compliant data stores.

</comment><comment><USER11> "The first enemy of performance is multiple machines. The fewer machines that need to talk to perform a transaction, the quicker it is."

That is not strictly accurate. He's taking one aspect of performance - communication latency - and expanding that to be a universal truth of performance.

Pixar's render farms are good. Google data centers are good.

When you're CPU bound, more CPUs can make you faster. Note the specific use of the word "can," as in "sometimes."

<comment><AUTHOR> (blog author) conceded

Listing all the exceptions that prove the rule wasn't quite the kind of programmer that I was ranting against

<comment><USER12> You might find that Gunther's "Universal Law of Computational Scalability" to be enlightening.

</comment></comment></comment><comment><USER13> For most startups, embracing a cloud architecture just makes sense. You're building an MVP and want to get it out in front of users. Deploying on something like Heroku and using the add-ons is one of the best ways to focus on your product and not on your server. Then when you have a success, step back and evaluate your tech stack.

To me, the primary advantage of all this new-fangled web server technology is the improved developer experience, not the performance implications.

<comment><USER14> If you can put together an app on Heroku, you can configure a web app server. I don't really see how Herkou saves much work over AWS and Linode. It might take a few minutes or a few hours, but if you know how to SSH in and run "rails server" you've got a platform for your MVP.

You can then easily evolve your app server in whatever direction you need to.

<comment><USER15> Heroku gives you a load balancer and auto-scaling. Time not spent in having to configure and maintain that piece of infrastructure is time spent in working on the MVP.

Another benefit of writing code targeting platforms like Heroku is that when your app gains traction you can easily scale since the app would've been (forced to be) written keeping horizontal scaling in mind.

<comment><USER14> What are the odds that your MVP needs load balancing and auto-scaling? It's far more likely that your app could run in a single process on a single box for a very long time.

<comment><USER16> As always, it's a matter of thinking about that up-front.

At what point is this a project that can be considered self-sustaining? (i.e. pays for its own development). Can you reach that point with a single box?

And if you can, do you have some leeway for growth after that point so you can actually develop a more scalable solution?

For some projects, that results in being OK with a single proc/single box approach. For other projects, you realize that unless you acquire ${LARGE_USER_COUNT} users quickly, you might as well give up on it - so you have to build in some scalability.

There's also expected growth rate - if for whatever reason you think your project might easily grow from single box to "needs more than one" in a short amount of time, you better plan for that.

It's that whole "horses for courses" thing ;)

</comment></comment></comment></comment></comment><comment> DanI-S This article starts by saying that there is something badly wrong with modern programmers.

It then details and critiques the way a typical one-man, one-site 'startup' is using discrete 'cogs' to build his system, presumably whilst learning how to market, build customer relationships and develop a beautiful and compelling product that makes enough money to keep him afloat.

I think the author may be missing the point. An elegant and sustainable back- end does not directly correlate with an elegant and sustainable business.

<comment><USER17> I don't think so.

Is installing and configuring Redis, installing and configuring a client library, and integrating the usage of that client library with your system really a better use of a one-man startup developer's time than writing

      new HashMap

and going back and fixing it later if it matters?

I had a three hour argument the other night with a developer trying to implement some sort of complex logic involving caching for a fairly small blacklist file. I eventually had to make him go away and benchmark it ... at which point he realised what my original point was - loading that file off disk and parsing it on every request it was needed was actually faster than talking to a cache to get a pre-parsed version.

Overengineering is still overengineering, even when most of the components you use to do it are provided by somebody else.

<comment><USER18> I see your point, and if all you need is a HashMap then use a HashMap.

But if that data in the HashMap must be available to another process, or you need more "features", Redis suddenly looks like a very easy solution.

<comment><USER19> The point is that you don't need multiple processes and Redis most of the time. Your site can easily be served from one box and one process.

<comment><USER15> Even multiple threads - any sort of concurrent access/modification on the same dataset becomes problematic if you just use a HashMap.

Sites that have any kind of download/upload component, even though does not have too much traffic, will need to serve multiple requests using threads/processes.

That is where we normally use relational database. However Redis presents a way to be faster than conventional databases by storing everything in memory. This is as close to a concurrency-safe HashMap that you can get with the least amount of effort.

<comment><AUTHOR> But Java comes with several currency-safe hash-maps and trees and such - <USER2> have you been?

If you think that blocking TCP calls to a redis server that serialises everything is going to be faster than a `new HashSplayTree<String>()` you're absolutely bonkers.

</comment></comment></comment></comment></comment></comment><comment><USER20> I think this analysis is not quite as cut-and-dried as the author thinks it is.

1\. Latency. Yes, going out-of-process, even to localhost, is very expensive, and the person the author was responding to should realize that. On the other hand, synchronization is _also_ very expensive. How do they compare? I have no idea[0], and I'm not about to guess. The author shouldn't either.

2\. Concurrency. Paul Tyma specifically talks about a "synchronized LinkedHashMap" as the implementation of a cache, so I'm going to take him at his word, understanding it might be a simplification. A synchronized Map is a poor implementation for a cache, because reads will block writes when they don't need to. A better implementation would be a ReentrantReadWriteLock protecting an _unsynchronized_ LinkedHashMap. Redis gives you this behaviour for free (even if you don't know of the existence of ReadWriteLock).

3\. Memory usage. Let's be honest--Java is a _pig_ for memory[2] compared to C++, and this is nowhere more apparent than indexing and caching the guaranteed 8-bit strings you'd find in an email. If your whole purpose is to fit more lines into your cache it's genuinely worth considering breaking out of the JVM to exploit the smaller memory footprint of C++ strings (and this really only holds for caches).

Was using a LinkedHashMap a good idea for Mailinator? Probably, I definitely don't have any evidence or suspicion to the contrary. Is it sensible to say "COGS BAD! IN-PROCESS GOOD" for every use-case? Not really.

[0] If I had to guess I would imagine that going out-of-process is 1-2 orders of magnitude slower than contended synchronization. Anyone got any figures?

[1] [http://docs.oracle.com/javase/6/docs/api/java/util/concurren...](http://docs.oracle.com/javase/6/docs/api/java/util/concurrent/locks/ReentrantReadWriteLock.html)

[2] I would be very surprised if Redis was not more than twice as memory- efficient _for this task_ as a LinkedHashMap. I'm pretty sure that one could implement a C++ solution that would be 3-4x as efficient. This is really only of paramount concern in a caching context, but in that context, it's paramount, because the cost of missing the cache is so phenomenal.

<comment><USER21> Isn't a read-write lock only really useful if you have more readers than writers? I would not be surprised if the amount of incoming spam means mailinator has far more writing to do than reading.

<comment><USER20> Maybe! My point isn't that Mailinator made the wrong choice (in fact I said they probably made the right one)--it's that the decision for a situation we know nothing about is more complex than "Cogs bad".

</comment></comment></comment><comment><USER22> I think performance is far too often used as a reason to add cogs, others are far better. If you often replace parts, more cogs are great. We have a really low-yield setup at one of our clients that is nevertheless splitted: ane process imports media data from a huge number of content providers and is split into 3 parts - an importer that normalizes all data, a queue as a binding and a reencoding process. The reason why we did this is easy: the queue is running for two years straight now, the encoding process was deployed once last year (we changed our logging strategy) and the importer process is deployed around 4-5 times each week. Not having to bring the whole machine to a grinding halt on each of those occurences is a major benefit.

</comment><comment><USER23> It's about daring to KISS. Only a select few dare to stand up against the hype.

</comment><comment><USER24> > If you can use a local in-process data-store (sqllite, levelDB, BDB etc) > you'll be winning massively.

Hold on just a sec. SQLite? Isn't that essentially equivalent to saying "If you never have to concern yourself with database locking, you'll be winning massively?" How can we be talking about scalability and SQLite in the same article?

<comment><AUTHOR> If an rdbms suits you, absolutely start with sqlite.

Code cost of migrating to something external when thats worth it? About a connect string...

<comment><USER24> Well no arguments there. So is your point that small sites should focus on small site performance and not try to optimize prematurely for scalability?

<comment><AUTHOR> Yes, and furthermore its the complete ignorance of how technology works that could lead to someone imagining that Redis could be a faster LRU than a `new ConcurrentHashSplayTree<String>()` in a single-process Java server (or equiv).

Apart from all the subtlety of not throwing away evicted lines until the last mail that uses them is discarded and such.

How can people think that mailnator is slow because its not using web 2.0 sauce?

</comment></comment></comment></comment><comment><USER25> Maybe I'm being the kind of developer that the blogger was talking about, but would it be such a bad idea for a Mailinator like site to use Redis to store the email messages but hosted on the same box as the web server?

At least that way, if you started to hit memory limits it would be relatively simple to scale out to more machines by moving Redis to its own box. It would be a configuration change rather than having to re-architect your custom LRU cache.

Another benefit would be that you could get disk persistence for free while still staying fast. If Mailinator needs to reboot all the emails are lost. That wouldn't necessarily have to happen if he was using Redis.

<comment><USER26> Running Redis on the same server still adds overhead to the system, to store an object in a map that's on the Java heap doesn't require any inter-process communication or serialization. Plus it's another point of failure, what if the Redis process stops but the Java process is still running? If Redis is remote, what happens if the network goes down? Keeping everything within the JVM avoids having to think about those failure scenarios.

I don't know how Mailinator is coded, but I'd guess he hasn't written anything too custom for storing key/value pairs in memory, there are plenty of Java caching implementations, the key thing he has done is work out a way of reducing the duplication, which Redis won't provide out of the box.

Mailinator is a great example of having the minimal set of features required and no more. There's no logins, no setup steps and no guarantees. This allows Mailinator to run on such minimal hardware, adding disk persistence would add complication without making the product better, by definition the kind of emails you send to Mailinator aren't important, so if they're lost during the occasional restart it doesn't detract from the service.

</comment></comment><comment><USER27> As for the cogs argument, this is all I have to say: silicon is still cheap, and carbon is still more expensive.

</comment><comment><USER28> I think it makes a lot more sense to focus on 1) what differentiates you, which may well involve lots of custom code, and 2) finding a market that works out for you.

For mailinator, they were already popular, so it makes sense to do some one- off coding to make things faster/more efficient. Perhaps, were mailinator starting up today though, using Redis as a good first step would have beaten whatever they had before, and would have been 'good enough' for longer.

Once you've got to the point where you're getting popular, then worry about making stuff scale up.

</comment><comment><USER29> Scalablity is nice, but what about redundancy? Not every website can go down for 6 hours while a tech repairs a host in a data center.

There are also challenges with putting all components on a single host. It's simple, but the components are not all going to scale the same way. And depending on how the datastore is partitioned, you'll still make remote calls anyway.

<comment><USER17> I've seen at least as many outages caused by problems in the additional complexity implemented to avoid having a single point of failure as I've seen outages caused by having one.

Plus given something like drbd having a cold spare that's trivial to spin up isn't that hard to do (and has the nice advantage of being relatively data storage technology agnostic).

<comment><USER30> The not-so-nice disadvantage that your cold spare can't actually do any work (like serve read traffic) and that if your application itself corrupts data DRBD will dutifully mirror that corruption. Hopefully the spare can still perform well with cold caches, but I guess a slow site is considerably better than a dead one.

<comment><USER17> If your secondary is doing work, then you'll get a performance degradation from losing the primary anyway.

The difference here is that once the slave's warmed up you're back to full speed, whereas with a hot-spare-being-read-from the performance degradation lasts until you bring the other box back.

Any such corruption is effectively a buggy update - normal replication will propagate a buggy write just as happily, and even if it crashed the node entirely there's a good chance your application's retry logic will re-run the write against the slave in a moment.

</comment></comment></comment></comment><comment><USER31> By the same token, I've inherited projects where the developer did not take scalability into account and avoided "cogs" for quick development turn-around. Putting the "cogs" in afterwards was incredibly painful, and a lot of development effort could have been saved if some thought was put into the architecture.

Quips about premature optimization often make the assumption that any optimization is premature. If data or usage growth (or uptime guarantees, for that matter) is an inevitability, then its often worthwhile to have at least some plan to grow your system beyond a single machine.

</comment><comment><USER32> This reminded me of <http://teddziuba.com/2010/10/taco-bell-programming.html>

</comment><comment><USER33> the trouble is that the Cogs Model (as it is put here) allows you to get shit done with lower skill levels. sure, it won't be perfect. and yes, if you had better programmers you could do it better. but these are pragmatic timse for most of us.

so he's right (in the abstract).

but for the reality most of us operate in he's wrong because Done is Better than Perfect.

that said... the "New is Good" thing needs to die. We're not freaking magpies people.

</comment><comment><USER34> Is mailinator a profitable business, or a volunteer project accountable to no bottom line? Both are fine, but the difference may inform design choices.

How expensively does the developer value his time? Has he already made in investment in learning certain technology?

<comment><AUTHOR> You can get these answers by reading the mailinator blog as the article encourages you to ;)

</comment></comment><comment><USER35> I love posts like this because, love it or hate it, it gives me a checkmark of thoughts to compare my choices to.

I see three possible approaches, all with their advantages and disadvantages. (Of course people may fit between them with a mixture of attributes.)

1\. Monolithic - Build it all yourself, purpose built and high performance. This is why mailinator and plenty-of-fish are able to produce high thruput on a surprisingly small number of machines.

2\. Confederated - Completely distributed. Each machine is its own monolithic platform with everything from DNS to database, including web server on that node, but a cluster of nodes gives you scalability, and workload is distributed across the cluster. (I'm not aware of any examples of this, which is why I'm building Nirvana.)

3\. COGS: You build your cluster of machines by architecting a system whereby you minimize (but not eliminate) single points of failure. You have N web server machines and X database machines and you seek out really high performance open source cogs to keep the number of machines low (e.g.: Redis, MongoDB, etc.)

The COGS approach is often taken with the idea that we need something really fast. MongoDB being fast (and "SQL") are the reasons its often chosen. Redis being fast is given as a key advantage (which is relevant for an in memory database, sure.) Node.js is often chosen for similar reasons.

But the ends result of the COGS approach is a brittle architecture. You may have multiple redundant web servers but the thing that distributes loads is a SPF. More specifically the architecture is complicated- each machine has a different configuration, etc.

With Monolithic, you get performance, and save hosting costs, and you can probably scale pretty well because you know your system really well, and you've squeezed out a lot of the inefficiencies that come from being generic (in the cogs approach) such that you can interoperate.

What I think we should see more of is confederated- no machine is a unique snowflake. Every machine is identical to every other machine. This way configuration becomes dead simple-- just replicate your model node, bring it up and data and load starts going to it.

This can be done with cogs- but they have to be fully distributed cogs. An example is Riak (Which hit 1.1 yesterday) which is open source and written in erlang and probably loses to nodeDB in every single single node benchmark you can come up with (not that the Basho people have designed it to be slow, quite the contrary.) But where's the fully distributed web platform for such an architecture? (If you have an answer, please make this question non- rhetorical. I'm putting a lot of time into building one because I couldn't find one.)

An interesting thing about the confederated approach is, because each machine is identical, it could be built in a monolithic fashion. Thus super optimized for its purpose. I'm using a sorta cogs approach because there are many good erlang cogs to use in my project.

But I think the big mistake is to focus on single node performance these days. Servers are relatively cheap, and you need more than one anyway for redundancy, so might as well have a cluster and no single points of failure.

<comment><USER35> For the life of me, I can't edit the above post. 5 attempts, all eaten by the HN monster.

When talking about benchmarks, I meant to say: "and probably loses to nodeDB in every single one-machine benchmark you can come up with (not that the Basho people have designed it to be slow, quite the contrary.)"

Finally the conclusion of the post:

Further, the only inter-machine communication should be at the database layer. (very little needed elsewhere) so as a result:

1\. Confederation of nodes that talk to each other to keep the databases consistent. With RIAK this means that one update only affects three nodes (with n=3).

2\. The whole layer cake, DNS to Database, including web server, application services, queues, etc, is present on every machine. No single point of failure (if you use DNS round robin to spread load, otherwise your load balancer is the SPF).

3\. Further, this layer cake, while composed of erlang cogs is mostly monolithic, as far as the programmer is concerned. You write your code in javascript or coffeescript and push it into the database. Each node is like a google App Engine, and you write handlers, and those handlers are run concurrently across the system.

4\. Want more performance? Add servers, or upgrade some of your servers. Node went down in the middle of the night? Go back to sleep. (Or write a simple client test you can run from your iPhone to make sure there wasn't some sort of cascading failure and the service is still up.)

5\. Almost zero operations, zero cluster architecture engineering work. No worrying about EBS being terribly slow (go dedicated machines for these nodes, btw) or any of that hassles. The engineer just writes javascript handlers and worries about CSS and javascript for the browser, etc.

For me, that idea is nirvana. Nirvana may not be right for you... but confederation has to be the future.

<comment><USER36> The systems I work on are pretty sizable in scale, right now we are doing about 120 million calls a day on one of core clusters. I don't claim to be the end all authority on scaling, but I do have some observations based on what I've dealt with.

First off, that type of architecture is brittle to logic changes. If you have a completely static architecture that you don't need to change it may be fine, but deploying those changes to every machine in the cluster is problematic.

Second, not all components have the same underlying machine requirements. For instance, our nginx servers don't need much ram, but the HAProxy load balancers with nginx that terminate SSL need a lot of Ram and a good chunk of CPU. Hadoop works better with JBOD (Just a bunch of disks), whereas cassandra seems to work better with a raid 0 configuration. Certain layers like the Nginx through certain paths have real time requirements which means ultra low latency. Other things need to operate against massive data sets and compute answers in a few hours.

So, not every machine in your architecture can have all of the services required by every other part of your architecture. A lot of it depends on workload types and what the underlying requirements are for your system. There are many more reasons, but I'll leave it at those for now. Ultimately the post is right that a single machine can work very well, but it's also misguided in just dismissing the HN commenter. There are many other cases where distributed architectures are required. Guaranteeing robustness and performance in the face of service and machine failures is very difficult, and is essentially impossible on a single machine.

Which approach you apply depends, it depends on the unique situation and the unique constraints you have. Using a single model to solve all problems seems to be worse than using no model. Learn multiple models, learn how and when to apply each (yes - for those of you in the class, I'm taking the model thinking class :) ).

<comment><AUTHOR> The kind of programmer I was ranting against is the kind who thinks redis LRU is faster than `new HashSplayTree<String>()`

Apart from missing the subtle bit about overriding eviction...</comment></comment></comment></comment>


ML with Android 11 - <AUTHOR> Hey,
I open-sourced this repo by me demonstrating how you can get started with Machine Learning in Android 11, all that is new. I further even explain how the code works so you can very easily get started with implementing Machine Learning in your Android apps with cool examples! Looking forward to contributions or suggestions.
Leave me a star if this looks good to you, helps me a lot.
https://github.com/Rishit-dagli/ML-with-Android-11 <comment><USER2> What part doesn't work with Android 10?

<comment><AUTHOR> ML Kit has a few new models and better support for on-device ML and the ML Model Binding is completely new and that's what the repo demonstrates too.</comment></comment>


We need to fill 'new collar' jobs that employers demand: IBM's Rometty - <AUTHOR> https://www.usatoday.com/story/tech/columnist/2016/12/13/we-need-fill-new-collar-jobs-employers-demand-ibms-rometty/95382248/ <comment><USER2> Maybe I missed it but there was no discussion of what skills go into a "new collar job."

Maybe it's called that because your job skills will change so frequently, and your job security is so low that your collar is always "new."

The whole discussion was basically water vapor - 11x increase in [metric] compared to low income schools. Wow great! What time period, what jobs, what skill sets etc...?

Sorry for being negative but this is an empty carb article when we need high protein.

<comment><USER3> I think that's exactly it. People need to be adaptable and it's not about teaching any one particular skillset, but moreso how to become a lifelong learner. The era of doing a couple of repeated tasks over and over again is gone, it is a new day where people do not need to perform menial jobs and can be _freed_ for more creative/mindful pursuits. In the short-term this is going to have negative effects of people being displaced, discouraged and lacking purpose. As with a lot of complex problems I think this may be a generational shift in thinking.

<comment><USER4> "Man, I can't wait for all those useless old day people to die so we can have our utopia."

PM me, I have a modest proposal you might be interested in.

<comment><USER5> There have been a multitude of generational shifts over the years. If you think that thinking it is happening (again) and that being hopeful that people move on is a bad thing, I'm sure you think of the shift away from subsistence farming was just as awful.

<comment><USER4> I think the thing that is awful is the inhuman speed at which those shifts are taking place, and the callousness by those pronouncing the change to the fates of those left behind, because they are sure they won't be. If we are about to put a whole bunch of people out of work for the rest of their lives, we better be damn sure we have a safety net for them. Hope is the greatest of all the evils that escaped from Pandora's box, because it soothes a guilty conscience but does not effect _action_.

</comment></comment></comment></comment></comment><comment><USER6> It's not "skills". It's "skills at the cost we want". Market forces will generally bring people with skills when the pay rate is high enough. If skills are so important, why not have a company train a person for the job?

<comment><USER7> Haven't you heard? Now universities are supposed to be glorified vocational schools where you pay for the privilege of company training that will be obsolete sometime in the decade after you graduate (but hopefully not before!).

<comment><USER8> I wonder why big companies like IBM don't just acquire large private universities and offer a traditional 4 year co-op experience.

They could subsidize education and 'guarantee' a job at IBM upon graduation. And shift the curriculum as needed for the company, provided they give a typical core education that you would find at any typical 4 yr college.

Heck if they get a D1 football school they can pump a bunch of money into it and leverage the exposure for advertising.

<comment><USER7> Why should they? Getting it for free is a pretty sweet deal.

<comment><USER8> Colleges make a lot of money (the good ones, anyway). And provide a unique source of brand equity.

<comment><USER7> There are lots of markets that IBM could presumably get into and make money but it's not clear they're all good ideas.

</comment></comment></comment></comment></comment></comment><comment><USER9> "New collar" is marginally skilled people who can fulfill a set of tasks without a lot of upward mobility. Support techs, call centers, etc. Employees get a job that pays better than fast food, employers get disposable employees who don't voluntarily churn.

Basically the next generation of mainframe operators, except with public funding of their vocational training.

<comment><USER7> Call centers have really high churn because, while the pay is somewhat good for a job requiring no skills, it's a miserable job associated with exogenic depression.

<comment><USER10> My mother works at a call center, and according to her, the churn is caused by misplaced expectations.

Basically, fresh hires have to take calls without appropriate training. Then they make lots of mistakes, or redirect most cases to more experienced colleagues. Because of this, the service level isn't met, and everyone is let off again. Then the cycle starts with new hires, who - _surprise_ \- aren't any better.

<comment><USER9> Call centers are weird. They treat people like cattle, and expect good outcomes.

I worked for a company that was apparently some sort of progressive beacon about 20 years ago. They treated people well, trained them for a month before they took a live call, and even promoted people out.

There was an annual cycle (this business peaked from March-September), but many employees would return and re-qualify. We used to hire 3-4 a quarter as IT techs (out of about 300 agents), and probably about half developed into either IT professionals or went back as call center managers / escalation agents.

<comment><USER7> I read that a lot of call center luminaries were former Taylorist factory managers, which would make a lot of sense if accurate.

</comment></comment></comment></comment></comment><comment><USER11> The funny reality is that every mid-sized company has openings for tech related roles. It's just that none of them are willing to pay for any level or skill or expertise unless it's geographically close enough to the bay area. I'm sure that there are a lot of ways to make companies more efficient with technology but at the same time they look at technology as a cost-center and not something that is generating money.

<comment><USER12> > _unless it 's geographically close enough to the bay area_

I encourage this. Two observations. One, most companies hiring for these roles ( _i.e._ growing fast) are in the Bay Area. Two, I've seen a material difference in performance between support that meets, in person, with the main office ( _e.g._ management, engineering and sales) once a month or quarter versus those who just join on calls. The number of times a support person's recounting of some random interaction is overheard by someone who makes a decision based on that story is huge.

The big issue is the Bay Area's old timers are attempting to control the gains from this economic activity through their control of its real estate. This, in my opinion, is a national structural problem more than a local one.

</comment></comment><comment><USER13> I think they hit on a real tension, but their interpretation of what is needed is wrong. The shift I think we need to see is management as "doers" rather than everyone being able to do everything. That is middle management needs to have at least enough skills to identify problems and act as a project manager rather than management for the sake of management. With that you'll have teams that look like proficient generalists at the middle/top level and then deep dive specialists underneath them. It's kind of a failure of the modern big co. that the only way to advance is through management rather than some sort of journeyman expert track which is what is really needed.

</comment><comment><USER14> IBM will offshore 8 out of 10 positions by 2017 [https://www.theregister.co.uk/2016/03/07/ibm_offshoring/](https://www.theregister.co.uk/2016/03/07/ibm_offshoring/)

Have fun with your "new collar" \- don't let it choke you too much.

<comment><AUTHOR> Exactly this. Mixed with all of the RA's going on at IBM, IMHO, this appears to be a smoke screen to justify their search for a cheaper workforce. The talent is there (or was there, in the expensive, experience employees). They just do not want to pay for it.

</comment></comment><comment><USER15> I'm not sure IBM is the corporation best able to tell us what the future will need.

<comment><USER16> IBM does do some high quality development and research. However, many of their historical cash-cow businesses are in secular decline. Most likely, IBM will remain important, but smaller.

</comment></comment><comment><USER17> A non-bachelor's education program seems like a great way to help. Many people attend university without a specific goal because they believe it's required in order to get a decent job. They believe that because for the most part, it's true. But perhaps employers just use it as a simple signal/shibboleth. If so, maybe "tech trade school graduate" would be just as good and hopefully more cost effective.

</comment><comment><USER18> I live in NYC and note that Google owns the 3rd largest office building in the city which is located in Manhattan and uses it for engineering. Many of the top technical people in the country want to live and work in Manhattan.

IBM HQ is located in NY State and headed by an engineer (Rometty), but I'd argue the difference in thinking between Google and their engineering leadership and IBM and their leadership is night and day. IBM has a lot of engineers and researchers in Westchester and other parts of the state, but not in the place that people want to live.

Notably, of the large tech firms of Amazon, Microsoft, Facebook, Apple, Oracle, IBM, only Google has the right idea of having any meaningful presence in NYC.

If the firms other than Google are truly serious about hiring top tech talent, they like Google, would have a major presence in NYC.

</comment><comment><USER19> Hmm, IBM was just laying off huge swathes of it's US workforce...

[https://www.theregister.co.uk/2017/03/31/ibm_bloodbath_conti...](https://www.theregister.co.uk/2017/03/31/ibm_bloodbath_continues/)

<comment><USER20> Exactly. IBM's business model these days is like that of a lot of other companies': Lay off your seasoned employees and replace them with lower- skilled low-benefits fungible contractors who cost half as much.

<comment><USER21> > IBM's business model these days

That's been their model for a long time. They aren't known as "India Business Machines" for nothing.

</comment></comment></comment><comment><USER22> TL;DR; Big business wants a big fat government handout.

</comment><comment><USER23> I don't understand why this is a problem. There have always been skilled technicians in the mechanical world. Welders, mechanics, lathe operators, craftsmen.

There are a huge number of jobs that you need to know how to use computers but dont need to know how to balance a binary tree. I'd think most of the new millennial generation would be perfect match already, and lots of other generations would be keen to do some night courses and/or on the job training to specialize in whatever is needed.

<comment><USER24> An enormous problem is this:

"We want someone with years of experience, but we want to only pay an entry- level wage." \- If most companies were honest

A friend of mine is still struggling with this. Nobody wants to hire him, because he doesn't have years of _professional_ experience and didn't have access to a good four-year college where he lives (Nowhere Wisconsin), and there are medical complications preventing him from moving away.

I personally taught him a great deal about programming and security. He's studied computers and networks for years before we met. He's talented, coachable, and willing to learn more.

The market fails people like him.

<comment><USER25> > The market fails people like him.

How? Doesn't this just imply that there is enough supply for those companies that want to pay a lower wage?

<comment><USER24> > How?

Preventing someone from entering the industry fails the person.

> Doesn't this just imply that there is enough supply for those companies that > want to pay a lower wage?

If you ignore the human aspects entirely, sure.

There's no telling what heights he could climb to if given the chance, but nobody wants to do that.

They want years of professional experience before they hire someone. But they only want to pay entry level wages. This creates a catch-22:

If you have the professional experience required, you can find a better paying job elsewhere.

If you have no professional experience, you can't get an entry-level position.

</comment></comment></comment></comment><comment><USER26> What jobs exactly are they talking about?

</comment><comment><USER27> I think the main thing here is an acknowledgment that automation will greatly disrupt the workforce. Simple, automatable work will be, and greater effort will be necessary to prepare displaced workers for the remaining opportunities. Not sure what skills this would require and whether this should be the responsibility of the government/universities or the corporations in charge of the hiring and retraining, but I think that's more the point than "IBM wants cheaper labor"

</comment><comment><USER28> There are similar programs that are used in the UK where kids do a ride-along at a tech firm and then after a year they disappear forever. It's frustrating because it is unwise not to shop around and all you get is a warm body for a year or so.

</comment><comment><USER29> The article wasn't very specific, I wonder what kind these so called new collar jobs are?

</comment><comment><USER30> What would the update to the Perkins Career and Technical Education Act entail?

</comment><comment><USER31> Far as I can tell, the main new idea here is that new rhymes with blue?

</comment><comment><USER32> This seems to be the original source: [https://www.usatoday.com/story/tech/columnist/2016/12/13/we-...](https://www.usatoday.com/story/tech/columnist/2016/12/13/we- need-fill-new-collar-jobs-employers-demand-ibms-rometty/95382248/)

<comment><USER7> Is that different than the link?

<comment><USER32> It was, until the mods changed it.</comment></comment></comment>


Association of insulin resistance marker with severity and mortality of Covid-19 - <AUTHOR> https://cardiab.biomedcentral.com/articles/10.1186/s12933-020-01035-2 <comment><USER2> Please note:

The calculation of TyG is ln (fasting blood sugar) x triglycerides/2). Many studies make the error of calculating it as (ln (FBS x TG))/2\. The only online calculator I've found, I think, falls into the latter category, or has worse errors - I didn't go through it too rigorously, but I put in values beyond what human life can sustain and didn't get close to the cut-off for this paper's bottom risk tier.

If you look at studies/calculator using the latter calculation, it looks like this study looks at _really, really_ severe diabetics.

If you compare with the appropriate calculation, though, they're looking at more run-of-the-mill "not optimally treated and obese" diabetics.

Hosseini 2017 did a paper analyzing a number of other TyG papers and calculating results under both calculation methodologies, for context.

Please also note that this paper does not state _when_ the results were collected. Insulin resistance/hyperglycemia is a symptom of sepsis - if these labs were drawn on already-severe patients, it would be entirely unclear whether they reflect a cause or an effect (or, as is almost certainly the case, both!).

<comment><USER3> > The calculation of TyG is ln (fasting blood sugar) x triglycerides/2).

You have a extra right parenthesis, which makes it ambiguous. Do you mean

ln (FBS) x triglycerides/2

Or

ln (FBS x triglycerides/2)

?

<comment><USER4> Doesn't matter since both multiplication and division are...commutative? Don't remember the terminology but (10x2)/4 == 10x(2/4) == 5

<comment><USER5> It matters here because he is using ln, and we don't know if we should stop at the first right parenthesis or the second.

The word you are looking for is associative.

<comment><USER6> Ooof, thanks for that. I didn't realize that was the natural log function because of the space. My brain was parsing it as the word "In" and essentially ignoring it.

<comment><USER7> There shouldn't be a space IMO, reading it out of context I couldn't see what the issue was either as I too was not parsing the ln as log_e.

        ln x

or

        ln(x)

but not

        ln (x)

</comment></comment></comment></comment></comment></comment><comment><USER8> Covid-19 is a very strange disease, it seems like it is amplified either way (severe vs. non-severe) depending on health. This seems different from the flu as the flu hits everyone very hard, the elderly/sickly especially hard. With covid some people who have it, do not and will not have any symptoms which cannot be said for the flu. I feel like the insulin marker data is an albatross, having high TyG means alot of systems in your body are not doing well, and the virus attacks weakness, it(covid-19) is also found to produce extreme clotting so that is probably why people with diabetes/heart disease and hypertension are all at high risk.

<comment><USER9> Asymptomatic infections are about as common with influenza as with SARS-CoV-2.

[https://www.ncbi.nlm.nih.gov/pmc/articles/PMC4586318/](https://www.ncbi.nlm.nih.gov/pmc/articles/PMC4586318/)

Some influenza strains hit young, healthy patients harder than the elderly by triggering a cytokine storm. This was particularly bad in the 1918 H1N1 pandemic.

[https://www.ncbi.nlm.nih.gov/pmc/articles/PMC4711683/](https://www.ncbi.nlm.nih.gov/pmc/articles/PMC4711683/)

</comment></comment><comment><USER10> I've suspected for a long time that Insulin resistance is going to be one of the next big areas of focus for public health, but I thought that it was going to happen the moment Apple finally figured out blood glucose measurement through the skin. I did _not_ see a pandemic being part of it.

<comment><USER11> I love my Apple watch but I am astonished at your faith in their ability to do noninvasive glucose measurement. People have broken their picks on that particular coal face for decades.

For that matter DM2 is an area of quite active research (and, like diagnosis, has been quite active for decades) as the financial payoff for any success is enormous.

The only downside for transdermal diagnosis is the lack of consumables, which makes it a tough market to enter and to be funded for. That _is_ an area that's good for Apple as they are already selling the platform, so this would be a feature that would add to sales. And one I'd use.

<comment><USER3> O2sat measurement has been noninvasive without consumables for a long time and many phones can do it now. Why do consumables matter?

<comment><USER11> Investors don't typically like diagnostics as the margins and volume tend to be quite low. They also tend to be more "vitamin" than "aspirin".* Consumables, a least, give you recurring revenue and even in some cases the opportunity for a razor-and-blades model.

You'd be surprised how many med products are designed specifically to require consumables.

* (funny analogy to use in a med context)

</comment></comment></comment></comment><comment><USER12> Insulin Resistance is the start of (all?) metabolic disease. So easy to resolve using fasting, intermittent fasting, keto, carnivore etc diets.

Unfortuneately it slowly builds up over decades and only once disease has progressed do Drs move on to treat the resultant disease (and mainly with cholesterol lowering drugs).

Instead of measuring fasting glucose levels (which indicate diabetes), insulin levels should be measured as they are the leading indicator.

<comment><USER13> > _So easy to resolve using fasting, intermittent fasting, keto, carnivore etc > diets._

Or, you know, you could resolve it by eating a balanced diet too.

<comment><USER14> On my mother's side of the family they were practically vegetarian or normal as it was called back then. Vegetables all week and maybe on Sunday a roast probably fowl of some sort.

This was during the 1940s. There were nine children and the parents on a farm in a small rural area. So no extravagant purchases no pop, candy, etc. My mom told me one Christmas her present was an apple and she was excited! The apple came from the tree out back.

Sounds good? But all the women (grandmother and aunts) in the family developed diabetes, one male (uncle) too.

Type 2 diabetes isn't always due to a poor diet.

<comment><USER12> All carbohydrates become sugar, sugar elevates insulin, constantly elevated insulin leads to diabetes.

I'm not sure all the causes of Type 2 diabetes but I would wager that the current epidemic of Type 2 Diabetes is caused by too much sugar.

<comment><USER13> It is not currently established what the exact relationship is between sugar in your diet, obesity, diabetes. They are all basically risk factors for the next one, but they definitely don't _cause_ (in the strict scientific meaning of the term) one another---there is nowhere near enough scientific evidence that would support that. There's enough uncertainty about the whole process that saying "avoid known risk factors" is about the best advice you can get.

</comment></comment></comment></comment></comment><comment><USER15> Given that insulin resistance is strongly correlated with obesity [1], I'm surprised that wasn't a factor they controlled for, especially since the respiratory difficulties associated with obesity seem to be a significant risk factor for death with Covid19 cases.

1\. [https://obesitymedicine.org/obesity-and-insulin- resistance/](https://obesitymedicine.org/obesity-and-insulin-resistance/)

</comment><comment><USER16> Lets not confuse correlation with causation. All this study shows is people with insulin resistance are at significant risk of dying from Covid, it doesn't identify what actually kills them. However, if you look at the role Vitamin D plays [1] in suppressing cytokine storms, which is what actually pushes over an organism to the point beyond recovery from Covid, and then understand that Vitamin D deficiency is common [2] in Type 2 diabetes, you can begin to understand the fuller picture.

1\. [https://www.medrxiv.org/content/10.1101/2020.04.08.20058578v...](https://www.medrxiv.org/content/10.1101/2020.04.08.20058578v4) 2\. [https://pubmed.ncbi.nlm.nih.gov/26375925/](https://pubmed.ncbi.nlm.nih.gov/26375925/)

</comment><comment><USER17> "[triglyceride and glucose] index was closely associated with the severity and morbidity in COVID-19"

So perhaps part of the reason why COVID-19 morbidity is lower in Japan/Korea/Taiwan compared to the U.S. is due to lower prevalence of metabolic syndrome. I wonder if that's also true for Europe.

<comment><USER2> > It suggests a protective effect of a keto/paleo diet.

No, if it can be taken at face value, it suggests a protective effect of a healthy lifestyle.

<comment><USER18> If taken at face value, it suggests a protective effect of low insulin resistance as measured by the TyG marker. Everything else is interpretations and chains of logical reasoning.

Neither of you are particularly wrong necessarily, but a third option is that someone could be sedentary and eating carbs every day and have low TyG. It's common to state that "activity XYZ will provide action-at-a-distance medical benefit ABC" because stating accurately what's going on takes more words that sound less certain:

"Paleo and keto diets may weaken Covid-19 by lowering insulin resistance"

"A healthy lifestyle may weaken Covid-19 by lowering insulin resistance"

But it's really worth saying it like this, even though few do. (And yes, these aren't 'maybe' enough, but they're an improvement.)

<comment><USER2> You replaced the word "suggests" with "may".

You're seeing a distinction between these two words that I apparently do not, since I take them both to indicate "this is a possibility, though not the only one, and a far from proven certainty."

I would add that, even there, my statement was predicated on making an inference about dietary habits - something I cast doubt on with the opening, "if taken at face value." Something I further opined on in my other post, where I pointed out that the paper may be reversing causality.

I feel like you're criticizing a strong inference having been made, that I think pretty clearly wasn't.</comment></comment></comment></comment>


Glibc is not Posix compliant - <AUTHOR> http://sourceware.org/bugzilla/show_bug.cgi?id=12724

<comment><USER2> Gnu's Not Unix.

That having been said, trying to maintain POSIX compatibility anyway is a good idea.</comment>


'9223372036854775807' == '9223372036854775808' - <AUTHOR> https://bugs.php.net/bug.php?id=54547 <comment><USER2> I can understand the rationale for coercing strings to numbers for an operation that is not valid on strings, but coercing strings to numbers _just because it's possible_ is clearly a terrible idea. It's like they looked at JavaScript and decided that the == operator was just not hazardous enough.

<comment><USER3> Please have a look at the comments by "jabakobob at gmail dot com" and myself ("email@example.com"). They explain why such behavior is actually good, in most cases.

<comment><USER4> Throwing away data without unavoidably good reason is BAD behavior. Period.

We've got gigabytes of RAM and terabytes of storage to work with; don't throw away characters in a string just because they don't fit in a compact data type used only because there is a passing resemblance of one to the other.

If I'm comparing two 53-digit barcodes, and they differ only by the last digit ( _checksum_ ), then it's very important that comparing those two STRINGS comes up FALSE.

<comment><USER5> > _If I'm comparing two 53-digit barcodes, and they differ only by the last > digit (checksum), then it's very important that comparing those two STRINGS > comes up FALSE._

Then use === and do a type-strict comparison.

        <?php

        // Prints bool(true)
        var_dump('9223372036854775807' == '9223372036854775808');

        // Prints bool(false)
        var_dump('9223372036854775807' ==='9223372036854775808');

<comment><USER4> Last week I spent 4 hours trying to find what turned out to be a missing = because C++ will not complain, but will behave very differently, when = is confused with ==. Now you want to add === to the mix?

I'll stand by the axiom that throwing away data should _NOT_ occur unless no other sensible option is available. If I'm comparing two literal strings, I shouldn't have to start with the obscure knowledge that a simple comparison will result in an aggressive attempt to perform two consecutive non-obvious type casts high risk of data loss.

I'm reminded of the great Belkin router fiasco: wireless routers were shipped with the "hold muh beer" great idea that random web page requests would be redirected to Belkin ad pages. I don't buy Belkin products any more (and that was years ago now) because knowing they would go there broke the trust that they wouldn't. Ditto here: if PHP is going to go to great lengths to try to throw away critical data (hey, I'm storing those numbers as strings BECAUSE I need _all_ the digits), then I can't trust that the language won't do other similarly stupid things. I'm working in an industry where such a cavalier attitude to data can cost MILLIONS of $$$ over one failure, and can't afford to use a language where such failures are systemic. That there exists a workaround is inadequate. </tangent>

Fine. I could use ===.

The problem remains that a fundamental axiom of the language design is that casting lossless to lossy data types, without direction or warning, is considered acceptable. Ya know, if PHP wants to convert my numeric strings to integers for comparison, fine ... IF it maintains precision and preserves all the data. I shouldn't have to know of and use other operators/functions to explicitly avoid a pathological pursuit of forgetfulness.

<comment><USER6> No offense, but it took you four hours to chase down a syntax error? If it survived long enough to see that kind of debugging effort, it was almost certainly dead code; seems like a unit test would have caught it before the first commit. And what compiler are you using? GCC certainly will issue warnings when the result of a = operator is used in a boolean context.

<comment><USER7> "No offence", yes, always a good way to start one's post! I think you missed out the "just saying", though. You need that too.

'=' vs '==' is not a syntax error. Consider "x=y=z" vs "x=y==z". And it's in somebody else's code. And they wrote it 2 months ago, but the programmer who's using it has only just started working with it. And they are super busy and don't have time to look at it. And it sort of looks like the problem is in the code you changed last week.

You can easily lose 4 hours over this stuff... have some imagination ;)

<comment><USER6> I'm just sayin', but this is a ridiculous strawman. (Well, you're right that it's not a syntax error in the sense of compiler output. I should have been more precise and called it a "syntax goof" instead.)

I addressed the "someone else wrote it two months ago" point above: If that happened, and this was in the code, _it was dead code for two months_ , because it clearly couldn't have been running correctly. That's a process problem, not a syntax issue, and the appropriate fix is clearly not to modify the syntax of the language.

( _Edit for ctdonath: good grief. 1.) the reply was to to3m's post, not yours. 2.) The "two months" thing comes straight out of his example, please read it. 3.) It was a JOKE, based on his chiding me for language. 4.) Why are you still flaming about this?_ )

<comment><USER4> "two months ago" is your own straw man. You made that up.

I'd written the code the day before, and it was failing a pre-commit unit test. As I posted elsewhere, this kind of "forgot the second =" error _can_ compile without warning, esp. within a complex evaluation. The process was running fine, as it caught the existence of the logic error early. That it took hours to find was a matter of tracing symptoms back to cause in an embedded system not easily debugged when running.

One could make a valid argument that this is a problem of language syntax, as everyone has been bit by the = vs == difference. As such, and in line with this thread OP, you'd think a new popular language would learn from that mistake and would not throw === into the mix as a solution to an even more obscure problem (casting a string to a float? really?).

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER8> interesting when you see your comments on hacker news as submissions to hacker news a day later: ( <http://news.ycombinator.com/item?id=3825132> )

"...My 5cents on that (recently published issues):

<? if ('9223372036854775807' == '9223372036854775808') { echo "I can not count!\n"; } ?> (see <https://bugs.php.net/bug.php?id=54547>)

or

built-in PHP web server dies with a large Content-Length header value: The value of the Content-Length header is passed directly to a pemalloc() call in sapi/cli/php_cli_server.c on line 1538. The inline function defined within Zend/zend_alloc.h for malloc() will fail, and will terminate the process with the error message "Out of memory". (see <https://bugs.php.net/bug.php?id=61461>) Luckily we are getting Javascript ready to replace all PHP on the server sooner or later ;-)..."

<comment><USER9> You are bragging as if you invented that bug :)

</comment></comment><comment><USER10> This behavior is documented here: <http://php.net/manual/en/language.operators.comparison.php>

      If you compare a number with a string or the comparison
      involves numerical strings, then each string is converted
      to a number and the comparison performed numerically.

<comment><USER4> Ah, an obscure point of absurdity which utterly kills my pending interest in the language. If this sort of thing exists under the hood, revealed only by a detailed analysis of the specification, what other nonsense is there? Going so far as analyzing a string to determine whether it consists entirely of numbers for the non-sequitur process of then and only then converting it to what it isn't for logical evaluation is working pretty hard to do something counter- intuitive; might be tolerable if it actually preserved all digits, but not only does it work hard to convert a string to an integer, it then converts large integers in to floating-point values - not just one, but _two_ layers of explicitly undesired and unnecessary and unreasonable typecasting.

I'm currently working with barcodes: numerical strings from 6 to 55 digits. In no way can I risk having one barcode be evaluated as equal to a literally different barcode just because the symbols in that string just happen to exhibit a passing resemblance to data of a different type.

Again, it's not just that it has loose typing. It's that it's taking what is OBVIOUSLY a string, converting it to an integer, THEN converting it to yet another data type which imposes data loss.

Intolerable for real-world use. A toy language. Alas, PHP, we hardly knew you...

ETA: Oh, I'd love to know the justification for the downvoting.

<comment><USER11> > Going so far as analyzing a string to determine whether it consists entirely > of numbers

I was about to give an outraged reply that, if PHP is like Perl, then it doesn't scan the string afresh, just keeps a flag indicating whether or not it thinks a string is numeric. However, it turns out that's not true at all. `Perl_looks_like_number`, defined in `sv.c`, calls `Perl_grok_number`, defined beginning on l. 577 (as of v5.14.2) in `numeric.c`, which (after some book- keeping) does this:

        if (s == send) {
          return 0;
        } else if (*s == '-') {
          s++;
          numtype = IS_NUMBER_NEG;
        }
        else if (*s == '+')
        s++;

        if (s == send)
          return 0;

        if (isDIGIT(*s)) {
          UV value = *s - '0';
          if (++s < send) {
            int digit = *s - '0';
            if (digit >= 0 && digit <= 9) {
              value = value * 10 + digit;
              if (++s < send) {
                digit = *s - '0';
                if (digit >= 0 && digit <= 9) {
                  value = value * 10 + digit;
                  if (++s < send) {
                    digit = *s - '0';
                    if (digit >= 0 && digit <= 9) {
                      value = value * 10 + digit;

and goes on and on and on and on in the same vein. Sheesh! (I didn't forget to close that last brace; the next line is de-dented, but that seems to be a mistake.)

<comment><USER12> Perl _does_ cache whether an SV contains something usable as an integer (the IOK flag) or a floating point number (the NOK flag). That's why you almost never see `looks_like_number` on its own and always called after using one of the appropriate flag checking macros.

</comment></comment></comment></comment><comment><USER13> This is why I like programming languages with type systems and "numerical towers":

        Prelude> "9223372036854775807" == "9223372036854775808"
        False
        Prelude> "9223372036854775807" == 9223372036854775808

        <interactive>:1:25:
            No instance for (Num [Char])
              arising from the literal `9223372036854775808'
                       at <interactive>:1:25-43
            Possible fix: add an instance declaration for (Num [Char])
            In the second argument of `(==)', namely `9223372036854775808'
            In the expression: "9223372036854775807" == 9223372036854775808
            In the definition of `it':
            it = "9223372036854775807" == 9223372036854775808
        Prelude>

Yes. Strings are not numbers.

<comment><USER14> You don't actually need type systems to test equality and identity the right way...

<comment><USER15> The point here is that these strings are neither equal nor identical.

<comment><USER13> Yes, it's the implicit conversion that matters. If you try to write 2 == 2.0 in Haskell, it will blow up, because doubles and integers are not the same type. You need to explicitly convert one of them to another representation before you can compare them. That guarantees defined and repeatable semantics at compile time, which I think is excellent.

(This is not strictly required, of course; you can write a typeclass that defines a two-paramater ==, instead of a -> a -> Bool, it could be a -> b -> Bool. But that's dumb, so nobody does.)

<comment><USER16> Uh? I just tried it and it works without blowing up.

Prelude> 2 == 2.0 True

</comment></comment></comment></comment></comment><comment><USER17> As a working programmer who has to use PHP, I just use === all the time and have long since moved on from even thinking about the insanity of PHP's == operator. Kinda like JavaScript programmers.

<comment><USER18> This. PHP's "==" is yet another trap of incompetent language design and almost all code that ever used it does the wrong thing for some inputs. $x == $y && $y == $z doesn't even tell you that $x == $z, much less that $a[$x] == $a[$y].

</comment></comment><comment><USER19> A somewhat related story dealing with MaxInt in Javascript.

One of the worst bugs I've encountered years ago involved the conversion of Javascript int from string to number. Javascript's long integer has only 53 bits, while most other languages have 64-bit long int. When the backend language generated Javascript snippets (JSON) containing integers greater than 53 bits, the horror started at the frontend. Javascript happily truncated the int to 53 bits upon conversion from string to int. It was not a happy tale since those long integers were account numbers. The wrong accounts ended up getting updated, randomly at first appearance.

<comment><USER20> I think the lesson there is that numeric types should only be used for things you actually want to do arithmetic with. An account ID that just happens to be all digits should still be stored and transmitted as a string.

<comment><USER19> The lesson I got was to be very careful about data type limitation when going across language boundary. The problem is not limited to numeric types. Different encoding and code page can screw up string values as well.

<comment><USER20> If you're not using UTF-8 everywhere then you're doing it wrong. Exceptions made for legacy systems, but you should get that data into UTF-8 as soon as possible.

<comment><USER19> It's unwise to lazily adopt a silver bullet without understanding the context and thinking through the consequence. I can say if you are not using XML with encoding specified to encode everything everywhere, then you are doing it wrong. You should get all your data into XML as soon as possible. Of course it sounds ludicrous.

<comment><USER20> XML is just one data storage and exchange format above many, with no particularly interesting properties and no compelling reason to use it. UTF-8 is the _only_ encoding that's ASCII compatible, widely accepted/expected, and can represent any text you'll ever encounter.

I can come up with half a dozen reasons to use something other than XML for data storage. I've yet to hear anyone give me a compelling reason to use something other than UTF-8 for encoding strings. Just because what I said is absurd when you replace UTF-8 with XML doesn't mean the original was absurd.

<comment><USER19> UTF-8 is not efficient for random access.

I don't have problem with UTF-8. I have problem with the silver bullet attitude advocating using an approach for all cases without thought. That's just intellectually lazy.

<comment><USER20> No encoding that can handle all the necessary languages will be efficient for random access.

I'm not saying don't think about it. But once you think about it, I think there's really only one sane conclusion to reach.

<comment><USER19> Never say never. UTF-32 handles them just fine.

<comment><USER20> Precomposed versus decomposed accents? Jamo versus precomposed Hangul characters? The Unicode code point is rarely useful thing to know about on its own, and code which assumes that one code point equals one "character", for whatever definition of a character is in use, is likely to work poorly with UTF-32.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER21> Some of the comments on the bug report asking for the operation of == to change are misguided. Such a change would break many real-world applications. As I understand it, PHP is casting number-like strings to integers, and this fails because both numbers generated from the cast are above PHP_MAX_INT, so their values are undefined.

This is easily solved by using the type-checking === operator, which exists for that purpose.

I hesitate to say that this is a feature, not a bug, but it is clear that this is documented behavior.

</comment><comment><USER22> In this perspective, writing `strcmp` everywhere is not boilerplate, but a requirement.

(Such that

        strcmp('9223372036854775807', '9223372036854775808');

returns -1, meaning the strings are _not_ equal.)

<comment><USER23> No, you just need strict comparison (like you need it in JS and any other language with weak typing):

        php > var_dump('9223372036854775807' == '9223372036854775808');
        bool(true)
        php > var_dump('9223372036854775807' === '9223372036854775808');
        bool(false)

<comment><USER24> I beg your pardon, but you do not 'need it in JS', if 'it' is referring to using === instead of == to compare strings.

Here is what node.js says:

        > "9223372036854775807" == "9223372036854775808"
        false

<comment><USER25> Ah but more fun with Javascript

>>> "9223372036854775807" == "9223372036854775808" false

>>> 9223372036854775807 == "9223372036854775808" true

>>> 9223372036854775807 == 9223372036854775808 true

I believe the grandparent post is more referring to "general" use cases then this one. Personally I now default to strict comparison operators both in JS and PHP unless I explicitly want a loose comparison and end up missing most of these strange vagaries these days.

</comment></comment></comment></comment><comment><USER26> The fact PHP fails at floating point math isn't news (and I swear I've seen this exact bug somewhere, same numbers and everything, somewhere else)...

Its the fact PHP refuses to fix it that is the news.

<comment><USER27> This sort of thing is an intrinsic property of floating point math. It has limited precision. When the numbers get sufficiently large, that precision is insufficient to distinguish successive integers. That is to say, this is symptomatic of PHP implementing floating point stuff correctly.

This is what ghci (Haskell) says:

      Prelude> 9223372036844775807 == 9223372036844775808
      False
      Prelude> 9223372036844775807.0 == 9223372036844775808.0
      True

This is what Python says:

      >>> 9223372036844775807 == 9223372036844775808
      False
      >>> 9223372036844775807.0 == 9223372036844775808.0
      True

Here is what SBCL (Common Lisp) says:

      * (= 9223372036844775807 9223372036844775808)
      NIL
      * (= 9223372036844775807.0 9223372036844775808.0)
      T

Lua:

      > print(9223372036844775807 == 9223372036844775808)
      true (!!!!!)
      > print(9223372036844775807.0 == 9223372036844775808.0)
      true

Javascript:

      alert(9223372036844775807 == 9223372036844775808)
      true (!!!!!)
      alert(9223372036844775807.0 == 9223372036844775808.0)
      true

Other languages that will also do this[1]: Javascript, Lua. Languages that won't: anything with actual, honest-to-god integers, and not floats or doubles masquerading as them.[2] Languages that actually handle numbers sensibly: Lisp.[3] I'm not familiar with any others that actually treat rational numbers like rational numbers, but I expect there are some. (It's still, of course, impossible to treat real numbers like real numbers, meaning that this sort of thing will also happen there.)

[1] Well, not the string-to-number bit, but whatever.

[2] Except for the niggle that they'll still do this when you're using floating point numbers, because this is what floating point numbers _do_.

[3] <https://en.wikipedia.org/wiki/Numerical_tower>

<comment><USER24> I think you may be missing the point, or maybe it's I who am missing the point. Your three very thorough examples are a good way of showing how (most?) languages handle floating-point arithmetic vs. arbitrary arithmetic.

But it seems to me - and let me stress that I am not a PHP developer and won't be bothered to install PHP on my machine at this time - that PHP is failing to exhibit exactly the behavior your code examples are giving.

Put it another way - type coercion 'run amok' being another thing entirely, you are correct that this bug stems from the fact that PHP is converting these integers to floating-point, and the standard floating point implementations will all behave in this exact way (thus, not a PHP bug.)

However, the issue here is that (again, "most?") languages also provide an easy way to get to arbitrary-precision arithmetic - and indeed, in the three examples you posted, you simply encode in the most natural way (by simply writing them) the two integers and they automatically compare correctly.

My understanding is that this is not the case in PHP, and that is a shame.

<comment><USER27> I agree that, when we are talking about high-level languages, I prefer ones that will transparently convert integers to bignum when required. I'm just replying to the contention that (paraphrased) "this is a bug in PHP's handling of floating point numbers".

<comment><USER24> Ah, point taken, sorry about that. :)

</comment></comment></comment></comment></comment><comment><USER28> This is how the strtol function in the standard C library works. Here's a test program:

        #include <stdio.h>
        #include <stdlib.h> /* strtol, strtod */

        /* Convert string to long and return true if successful. */
        int string_long(char *beg, long *num)
            {
            char *end;
            *num = strtol(beg, &end, 10);
            return *beg != '\0' && *end == '\0';
            }

        int main(void)
            {
            char *x_str = "9223372036854775807";
            char *y_str = "9223372036854775808";

            long x;
            long y;

            int x_ok = string_long(x_str, &x);
            int y_ok = string_long(y_str, &y);

            printf("x_str = %s\n", x_str);
            printf("y_str = %s\n", y_str);

            printf("x = %ld (ok=%d)\n", x, x_ok);
            printf("y = %ld (ok=%d)\n", y, y_ok);
            printf("x and y are %s\n", x == y ? "equal" : "not equal");

            return 0;
            }

And here's the output:

        x_str = 9223372036854775807
        y_str = 9223372036854775808
        x = 9223372036854775807 (ok=1)
        y = 9223372036854775807 (ok=1)
        x and y are equal

I compiled it like so:

        gcc -c -Wall -Werror -ansi -O3 -fPIC src/test_num.c -o obj/test_num.o

<comment><USER28> Incidentally if you try using those numeric constants directly in a C program, it fails to compile:

        #include <stdio.h>

        int main(void)
            {
            long x = 9223372036854775807;
            long y = 9223372036854775808;

            printf("x = %ld\n", x);
            printf("y = %ld\n", y);
            printf("x and y are %s\n", x == y ? "equal" : "not equal");

            return 0;
            }

The error message is:

        gcc -c -Wall -Werror -ansi -O3 -fPIC src/test_num2.c -o obj/test_num2.o
        src/test_num2.c: In function 'main':
        src/test_num2.c:6:11: error: integer constant is so large that it is unsigned [-Werror]
        src/test_num2.c:6:2: error: this decimal constant is unsigned only in ISO C90 [-Werror]
        cc1: all warnings being treated as errors

</comment></comment><comment><USER29> Judging by the huge number of stupid comments on that bug report this bug was posted on reddit.

If you don't actually use PHP (as most of the commenters seem not to) don't comment on the bug, it has nothing to do with you and you are just making noise.

</comment><comment><USER30> You can do literal comparison using ===

But the problem in my perception is that it is very error-prone. A less error- prone solution would be only convert one string value to number when the another is really a number. For example:

'9223372036854775807' == 9223372036854775808

<comment><USER31> > A less error-prone solution would be only convert one string value to number > when the another is really a number.

That is, in fact, exactly how JS handles it.

</comment></comment><comment><USER32> It's the same with JavaScript regardless of whether you use == or ===

9223372036854775807 == 9223372036854775808

true

9223372036854775807 === 9223372036854775808

true

<comment><USER33> Is _"javascript does it too"_ supposed to be a defence?

<comment><USER32> More of an observation than anything else. I don't actually use PHP but find these recent PHP focused articles are helping me learn at thing or two about languages I do use.

<comment><USER33> Fair enough.</comment></comment></comment></comment>


Signal-Flow Graph - <AUTHOR> https://en.wikipedia.org/wiki/Signal-flow_graph <comment><AUTHOR> I stumbled across a reference to this (known also as a "Mason Diagram") while reading _Talking Nets: A Oral History of Neural Networks_.[1]

Walter Freeman's reaction to them piqued my interest, and I thought some of the rest of you might find this of interest as well.

[1]: [https://books.google.com/books?id=-l-yim2lNRUC&pg=PA29&lpg=P...](https://books.google.com/books?id=-l-yim2lNRUC&pg=PA29&lpg=PA29&dq=%22mason+diagrams%22&source=bl&ots=k68zCSEYzn&sig=FwDN5g49qgkNYvyRT66zm07tclk&hl=en&sa=X&ved=0ahUKEwiEgrOIu- zMAhWH6YMKHZ67BHAQ6AEIMzAG#v=onepage&q=%22mason%20diagrams%22&f=false)</comment>


MetaMind – AI for Enterprise - <AUTHOR> https://www.metamind.io/

<comment><USER2> Wow that is a lot of buzzwords that I'm not sure can be implemented... the picture of the founder + team has a cute puppy though.</comment>


Unicode Alphabet Detection for Python - <AUTHOR> https://github.com/EliFinkelshteyn/alphabet-detector

<comment><USER2> Does something like this exist for Javascript? In particular I am looking for a function that tests whether a character is CJK or not.

<comment><USER3> CJK characters are stored in the range 3400–4DBF and 3400-4DB5 (could be others, but those are what Google comes up with first).

You can use JavaScript regular expressions to check for Unicode ranges. The challenge is that Unicode uses UCS-2 internally, and EMCAScript 5 doesn't handle surrogate pairs.

Thankfully, there's [https://mths.be/regenerate/](https://mths.be/regenerate/).

<comment><USER4> 3400-4DBF is CJK Unified Ideographs Extension A. The main block is 4E00-9FFF CJK Unified Ideographs.

See [http://en.wikipedia.org/wiki/Unicode_block](http://en.wikipedia.org/wiki/Unicode_block)

</comment></comment></comment><comment><USER3> Looks like this is a nice abstraction of Python's Unicode Database, "unicodedata."

<comment><AUTHOR> Yup. It does all of the stuff I had trouble finding and figuring out by myself. I'm sure more annoying corner cases will come up later on (as they always do with alphabets and unicode), and I'll keep adding to it.</comment></comment>


Alacritmux: Tmux Pane Font Resize - da-x https://medium.com/@danaloni/alacritmux-tmux-pane-font-resize-3bd07e186c <comment><AUTHOR> You could try opening an issue here and see if there is any interest in your protocol:

[https://gitlab.freedesktop.org/terminal- wg/specifications/is...](https://gitlab.freedesktop.org/terminal- wg/specifications/issues)</comment>


To Kill a Microservice: going from a microservice architecture to a monolith - <AUTHOR> https://medium.com/botify-labs/to-kill-a-microservice-d6c9e7ad444c <comment><USER2> So much manager-speak (velocity, pain points etc.). Indigestible for an enginner.</comment>


UW engineers achieve Wi-Fi at 10,000 times lower power - <AUTHOR> http://www.washington.edu/news/2016/02/23/uw-engineers-achieve-wi-fi-at-10000-times-lower-power/ <comment><USER2> The low-power devices don't actually generate any signal at all thus don't have to pay that expensive power cost. Instead a passive antenna is modulated to reflect or absorb ambient signal, the reflected signal conforms to traditional 802.11 packets. The ambient signals are created by a relatively high-powered device that is plugged into wall power.

Here is a 2 minute video showing an early prototype of their work from 2014:

[https://www.youtube.com/watch?v=snZWgAZqo2c](https://www.youtube.com/watch?v=snZWgAZqo2c)

<comment><USER3> I've looked at the paper [1], but I can't figure out how this is different from backscattered RFID with 802.11 on top. The paper says RFID requires a full-duplex radio while the WiFi chipset is orders of magnitude less expensive. Are they modulating differently or is there some RF magic?

[1] [http://passivewifi.cs.washington.edu/files/passive_wifi.pdf](http://passivewifi.cs.washington.edu/files/passive_wifi.pdf)

<comment><USER4> The technology is ~50 years old, and was originally invented by the Soviets to eavesdrop on the US embassy in Moscow.

[https://youtu.be/mAai6dRAtFo?t=9m35s](https://youtu.be/mAai6dRAtFo?t=9m35s)

[https://en.wikipedia.org/wiki/The_Thing_(listening_device)](https://en.wikipedia.org/wiki/The_Thing_\(listening_device\))

TL;DR Using a passive antenna to modulate a directed microwave emission.

<comment><USER5> Wow that's interesting, how did they find "The Thing"?

<comment><USER4> [https://en.wikipedia.org/wiki/The_Thing_(listening_device)#D...](https://en.wikipedia.org/wiki/The_Thing_\(listening_device\)#Discovery)

</comment></comment></comment></comment></comment><comment><USER6> This article is a few months old. The technology is now being commercialized by the same authors, as Jeeva Wireless: [http://www.jeevawireless.com/](http://www.jeevawireless.com/)

<comment><USER7> In case someone is wondering 'Jeeva' (pronounced as Jeev) means living thing in Hindi.

<comment><USER8> To add, Jeeva means living thing in Malayalam, another language from the south India. In fact, Jeeva is a common name in Kerala and Tamil Nadu, two states from the south India.

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

<comment><USER9> Very interesting, thanks. I know a South African family of Indian descent with that last name. They're the only Muslim family I've met with that name so I've wondered about its roots.

</comment></comment></comment></comment><comment><USER10> I wonder if you could use this technique to make a completely passive wi-fi device. Ie, no battery or plug of any kind, just using the power of the wifi emitter. I guess it would be similar to passive NFC, but at a longer range and driven by a separate device from the one that does the receiving. Or would the power requirements be too high?

Edit: I just realised that the earlier prototype video from the comments indicates that's the goal, but it's not mentioned in this more recent one. Instead they just talk about higher power efficiency. I wonder if that means they tried it and it wasn't feasible.

Edit 2: Aha, got it. There are three separate projects:

1\. Ambient Backscatter (2013): no external power, no base station (uses ambient frequencies like TV), not wifi, low data rate (1Kbps) and short range (<1 metre) [[http://abc.cs.washington.edu/](http://abc.cs.washington.edu/)]

2\. Wi-Fi Backscatter (2014): no external power, base station, kinda wifi (encodes data in the CSI/RSSI metadata and presence/absence of packets), low data rate (1Kbps) and slightly less short range(<3 metres) [[http://iotwifi.cs.washington.edu/](http://iotwifi.cs.washington.edu/)]

3\. Passive Wi-Fi (2016): low external power, base station, actual wifi (802.11b packets), high data rate (11Mbps) and long range (<30 metres) [[http://passivewifi.cs.washington.edu/](http://passivewifi.cs.washington.edu/)]

<comment><USER11> I doubt that a microprocessor will be able to operate solely off ambient RF, but I could see a low power microprocessor being combined with this and a betavoltiac for impressively long life. Using this with the new diamond battery that they have in the labs at the university of Bristol would enable the creation of wireless devices that last over 5000 years.

</comment></comment><comment><USER12> I invented a coffee machine which works using 10000 times less power: it works by deferring the actual coffee making to another machine you plug into another wall socket.

<comment><USER13> Your analogy is flawed: let me fix it for you. "I invented a battery powered coffee machine which works using 10000 times less power: it works by deferring the actual coffee making to another machine you plug into a wall socket. Now you can stop worrying about recharging the battery on the first coffee machine, and still enjoy your coffee just like before!"

With WiFi, the advantage is that battery powered devices like your smartphone will consume less energy. Sure, your router will draw more power from the wall socket, but you are effectively reducing power consumption where you actually are using WiFi the most, mobile devices that run on batteries.

<comment><USER14> Ty for the analogy, wasn't sure if I really figured what they were saying in the paper

</comment></comment></comment><comment><USER15> 10,000 times lower power, but achieving speeds up to 11Mbps

Being named passive wifi. Quite neat and could be useful for IoT considering also approx 100 ft distance

<comment><USER16> 100' is a very low distance for real IoT applications I've run across

<comment><USER11> A directional antenna at the active wifi radio would enable longer range. One interesting application would be the ability to dogleg a wireless connection between points A and B where there is no LoS to each other, but both have LoS with point C. It would be a low throughput link, but it would allow for an awesome implementation of a private two way communications system. I.e. Several miles without direct LoS between the two end points.

<comment><USER16> This is already a thing, however data rates tend to be slower

<comment><USER16> Yeah but it's easier to pair down the antenna and underpower the radio than to go the other direction :)

</comment></comment></comment></comment></comment><comment><USER17> This is great research!

10,000 times lower power is only for the "passive wifi" devices, but these passive wifi devices require a "heavy-lifting and power-consuming plugged-in device" nearby.

Assuming that device consumes no more than a traditional wifi device, then the overall system would consume:

        [usual consumption of 1 wifi device] + [# of passive devices] * [usual consumption] / 10000

So, if we want to calculate _per passive device_ it would consume around

        [usual consumption of 1 wifi device] / [# of passive devices]

In other words, the more of these devices, the better. Too few devices might not offset the plugged-in device energy cost.

<comment><USER18> I am just wondering if the plugged in part needs to transmit at full power all the time. This could seriously increase the overall energy consumption.

Plus, I have a hard time deciding _what_ it would transmit at full power all the time...

<comment><USER19> I'm not an RF expert, but it sounds like it would be transmitting an empty carrier wave, not a real signal. Think of it as a big light source and the passive transmitters as mirrors used to flash signals back and forth with reflected light.

(Of course you'd _also_ need a traditional wifi router for everything to connect through, and you might as well build that router into the same shell as the emitter thing, so it gets confusing. But the basic carrier wave wouldn't necessarily carry a signal.)

</comment></comment></comment><comment><USER20> It looks like this can only transmit, not actually receive and interpret data-- and if you listen carefully, this is the kind of applications they're suggesting.

That's good for sensor nodes reporting status, but not so good for interactivity.

<comment><USER19> I don't think that's right, except in an extremely narrow technical sense. This specific technology they've developed is only for low-power transmission, because receiving wifi signals can _already_ be done with little power. Device manufacturers can pair the new transmitter with any off-the-shelf wifi antenna for reception.

</comment></comment><comment><USER21> Interesting idea. Things like this generally need a bigger antenna, since they're getting power from it. It probably means the base station has to run at high power most of the time, rather than throttling down for short range transmissions. If it went all the way to full wireless power, like some RFID tags, it would be more useful.

High data rate capability probably doesn't matter. Anything that's receiving or sending a substantial amount of data is probably using more power doing something with it than sending it.

</comment><comment><USER22> Love to see someone makes watch/heart rate monitor with this technology that last months/years or maybe forever with tiny solar panel like what's on solar calculator.

</comment><comment><USER23> It would be great if this could be used in (new) mobile phones and tablets in a low power mode when you don't need high data rates.

</comment><comment><USER24> >Now, paper towels, coffee or sugar can communicate their status using WiFi.

Internet of edibles?

God help us all :)

<comment><USER25> You say that but if we could easily swallow or "tattoo" cameras/sensors, there are many medical upsides.

</comment></comment><comment><USER26> I wonder why there isn't a WEP-like protocol using AES-CCMP. (of course, without the problems of WEP)

</comment><comment><USER27> old news. I guess I remember this news in February here at HN

</comment><comment><USER28> This seem another wifi achievement only replicable in a desert environment, during a solar maximum, on the dark side of the moon, while holding a black cat.

If you are using a "wifi" antenna then that antenna is going to be picking up all sorts of little things. Normally these aren't much of an issue, but at these sensitivities suddenly that phone down the hall, the one not running at a 10e-3 power setting, is a real issue.

Also, February 2016?

<comment><USER29> There's nothing wrong with posting older material to HN if it hasn't had attention yet. I'm not sure if this story had, though.

The "new" in "Hacker News" is more like a second-hand clothing store in my neighbourhood that used to be called "New to You".</comment></comment>