Ask HN: chromium vs chrome - <AUTHOR>

I am not that persnickety, but I thought it would be cool if everything I did w/ browser was not somehow channeled back to google. It was my understanding that chromium does not do this. Is this true? How can it be true? Thanks HN! <comment><USER2> See here: [http://en.wikipedia.org/wiki/Chromium_(web_browser)#Differen...](http://en.wikipedia.org/wiki/Chromium_\(web_browser\)#Differences_from_Google_Chrome)

In particular: "RLZ tracking when Chrome is downloaded as part of marketing promotions and distribution partnerships. This transmits information in encoded form to Google, e.g., when and from where Chrome has been downloaded. In June 2010, Google confirmed that the RLZ tracking token is not present in versions of Chrome downloaded from the Google website directly or in any version of Chromium. The RLZ source code was also made open source at the same time so that developers can confirm what it is and how it works"

More details here: <http://blog.chromium.org/2010/06/in-open-for-rlz.html>

Plus Chromium is open source, so you're free to check that it doesn't transmit to Google yourself.</comment>


How Much Alcohol Is Safe to Drink? None, Say These Researchers - <AUTHOR> https://www.nytimes.com/2018/08/27/health/alcohol-drinking-health.html <comment><USER2> "Researchers". You mean people desperately trying to make a name for themselves with exaggerated pseudoscientific claims. The amount of food/diet related "studies" that have been retracted,contradicted and rinse/repeat is so staggering that "news" companies should stop publishing it because it's more harmful to the public than anything.

"Benefits of moderate alcohol consumption such as wine include a 30% reduction in the risk of heart attack compared to non-drinkers, a finding that has been repeated over 30 years and in various countries, according to Eric Rimm, a professor of epidemiology and nutrition who has been researching the effects of alcohol and chronic disease for decades at the Harvard T.H. Chan School of Public Health.

Additionally, alcohol consumption has been associated with a 30% to 40% reduction in the risk of Type 2 diabetes, compared to those who don't drink. "

[https://www.cnn.com/2017/04/21/health/wine-healthy-food- dray...](https://www.cnn.com/2017/04/21/health/wine-healthy-food- drayer/index.html)

How about moderation? I can't wait for the next studies:

"How much salt is safe to consume? None, Say These "Researchers"".

"How much sugar is safe to consume? None, Say These "Researchers"".

"How much water is safe to consume? None, Say These "Researchers"".

</comment><comment><USER3> They forgot to consider the 'brave new world' effect -- society crumbles if people don't get their soma.

<comment><AUTHOR> Ideally we should also skip or go easy on the best tasting food. Oh well..

</comment></comment><comment><USER4> One drink a day is quite a bit of drinking compared to what I consider normal, and the difference between 914/100,000 and 918/100,000 is small.

I'd say the advice that you can drink in light or moderate amounts without any significant risk is still sound. But if you're not inclined to drink for other reasons, you shouldn't start doing so for your health.

<comment><USER5> I don't know what circumstances you live under where that's the case. Most people don't limit to one, but also don't drink every day. In much of the US 5-8 beers, or similar mixed drinks is a totally normal, not even a heavy drinking night. This is repeated 2-5 nights a week, though some nights might be more like 1-3 drinks. I'm talking about standard alcohol units here.

<comment><USER6> 5-8 beers, 2-5 nights a week is a ton. This is not typical for most drinkers. That's up to 40 beers a week. 5+ drinks in a row is the definition of binge drinking.

[https://www.cdc.gov/alcohol/fact-sheets/binge- drinking.htm](https://www.cdc.gov/alcohol/fact-sheets/binge-drinking.htm)

 _" One in six US adults binge drinks about four times a month"_

Your "normal" is as many nights per week as the CDC claims per month, and the CDC claims this for only 17% of the population. Put another way, your "normal" is 4x as often and at least 3x more common than reality.

If you're hanging out with people drinking this much all the time, then you may have normalized it, but it's absolutely not normal for "much of the US".

<comment><USER7> Simply put, what the government describes as normal (or ideal) is far different than what the alcohol-consuming populace considers normal.

(Side thought: Some of the risks in that article are suspect. STDs and domestic violence? Those are reflections of the individuals using the drug, not the drug itself.)

<comment><USER6> This isn't the case of the CDC describing what _should_ be normal. I quoted a statistic about _actual_ consumption to contrast the anecdotal claim that binge drinking up to 5 times/week is "typical".

Now, if you don't like the standard definition of "binge drinking" that's fine. 40 beers/week is still very, very far from typical.

Edit: I don't find the risks to be particularly suspect. Drinking lowers inhibitions and reduces ability to engage in critical thinking. Drunk people regularly do stuff they regret later, ranging from saying embarrassing things to driving intoxicated to getting into physical fights with strangers, friends, and partners. Certainly the person having unprotected sex or assaulting their partner is responsible for their actions, but alcohol also makes those actions more likely.

<comment><USER7> Certainly agree that 5x a week isn't normal or generally healthy.

Risk-takers and mean people are more commonly heavy consumers of alcohol. They like the feeling as it eggs them on and self-justifies their actions.

But this does not mean that heavy consumers of alcohol are uncontrollably pushed to emulate the former.

Basically, the bad folks always ruin it for the docile rest of us.

<comment><USER6> > _Basically, the bad folks always ruin it for the docile rest of us._

To some extent, yes. But those who want to normalize and justify their drinking also wish to absolve alcohol of all association with these things even though alcohol absolutely increases their incidence.

You see the same bias in people who want to believe that drinking moderately is _healthier_ than abstaining. There's nothing actually supporting this, but the few flawed studies that show some minor benefit get published over and over in the news because it's what people want to hear. In reality once you filter out people who abstain specifically because of their health, all cause mortality goes up with any level of drinking.

</comment></comment></comment></comment></comment></comment></comment><comment><USER8> This study has a 95% uncertainty interval, and their conclusion is that alcohol consumption increases your risk from: 918 per 100,000 people from 914 per 100,000.

..I'd argue their conclusion is meaningless given the uncertainty interval.

</comment><comment><USER9> Why the repost? This article is from last year.

</comment><comment><USER10> No drug is 'safe.' But they save lives.</comment>


R.I.P. OpenSolaris - <AUTHOR> http://blogs.computerworld.com/16550/rip_opensolaris <comment><USER2> I have mixed feelings about this. I absolutely loathe the old, buggy, incompatible Solaris userland, and for me, Solaris can't die fast enough. OpenSolaris however seemed like a step in the right direction, keep the kernel and all the good things that come with it (DTrace, ZFS, etc) but drop in the GNU userland. I'd much rather Oracle kill Solaris proper and work on pushing OpenSolaris forward.

<comment><USER3> Ditto. I have to use Solaris 10 at work and it's a pain to compile anything for it, especiallly anything that uses a GUI. ZFS is a very nifty tool and Solaris has a lot of neat features, but it's a pain to work with. I much prefere the Gnu toolchain.

</comment></comment><comment><USER4> SunOS and later Solaris were my first real window into serious computing (along with IRIX). I'm kind of sad to see inevitable happening. It was a matter of time.

</comment><comment><USER5> Nice article. The point he makes about Linux devs vastly outnumbering OpenSolaris devs is true for all of the free operating systems. Look at the CVS commits in OpenBSD. You can count on both hands the number of 'primary commiters' Thousands versus dozens makes a huge difference as does corporate involvement. I like all the free/open source operating systems, but I tend to go with GNU/Linux for this very reason.

<comment><USER6> As a long-time user of Open/FreeBSD & Linux & solaris/opensolaris....

The point about # of devs is true - linux is the new _nix reference platform (well, not new anymore I guess). It used to be SunOS/Solaris.

OpenBSD has a small number of committers and developers more because of the attitude of it's community and head honcho - OpenBSD is fantastic at what it's fantastic at, but the developer community is very much "If you don't like the way we do it, F_* off" (which is perfectly fine...no moral judgement implied).

FreeBSD on the other hand doesn't get enough cred... it's solid, it's constantly incrementally improved. It's a single distribution with a very focused core - so while it doens't have all the fire and brimstone of linux, those FreeBSD guys have been cranking out solid, wonderful, well engineered and well documented code for a long, long time.

I'm often on the brink of wishing I could switch an enterprise to FreeBSD completely - the commercial support isn't all there, but from a purist point of view it's pretty much THE best free *nix out there, and I'm never really sure why it doesn't get the same focus linux does - I suppose it's just the way things went and media hype about the GPL.

<comment><USER7> For starters, there is no FreeBSDBuntu, and Ubuntu has done wonders flying the flag for Linux.

<comment><USER8> I haven't used it, but PC-BSD looks like the "Ubuntu" BSD.

<http://www.pcbsd.org/>

</comment></comment></comment></comment><comment><USER9> ... And right as I was putting some serious thought into using OpenSolaris with ZFS for my home file server. I wonder what the future of Solaris is now, too.

<comment><USER10> Me too. I was just about to pick this one up at the local book store. [http://www.amazon.com/Solaris-ZFS-Essentials-Scott- Watanabe/...](http://www.amazon.com/Solaris-ZFS-Essentials-Scott- Watanabe/dp/0137000103/ref=sr_1_1?ie=UTF8&s=books&qid=1279414152&sr=8-1)

Anyone have an idea of whats going to happen to ZFS? (licence change?)

<comment><USER11> The future of Solaris looks the same as its past: proprietary and very expensive (but they'll throw it in free if you buy a Sun server running Oracle).

</comment></comment></comment><comment><USER12> OpenSolaris is GPLv3, according to the article. Those who want to save it might take advantage of that. Try to pitch it to the FSF as the logical choice for the GNU kernel, instead of HURD.

Linux is GPLv2, not GPLv3, and there's no sign of that changing anytime soon, so it might be possible to interest the FSF on philosophical grounds to consider a replacement for Linux.

<comment><USER13> The article is wrong. OpenSolaris was never released under GPLv3. It is under CDDL. The reference the article points to is an obscure blog from 2007 which is obviously wrong.

<http://hub.opensolaris.org/bin/view/Main/licensing>

</comment></comment><comment><USER14> Now that Oracle has dumped it for good, I really hope that there is a resurgence of FOSS developers working on OpenSolaris to keep it alive and relevant...

<comment><USER6> Which parts of it are really valuable to the FOSS community.

The "zones" stuff is really only valuable for the big-iron systems, which you probably want/need support from Sun for anyway..... and if it's ZFS, the other big killer factor, FreeBSD is probably a better place to focus efforts than Solaris.

<comment><USER14> I think theres benefits with having a diversified free OS environment, and I think there are other benefits to keeping something like OpenSolaris alive versus some of the smaller Linux distros...for instance, if OpenSolaris is still used by the community then maybe some of the Oracle/Sun engineers will help add features during their off-work hours spare time.</comment></comment></comment>


Technical debt as an opportunity to accumulate technical wealth - <AUTHOR> http://firstround.com/review/forget-technical-debt-heres-how-to-build-technical-wealth/?_hsenc=p2ANqtz--kPw8wFvKVfV1GLca96jgrr2yWHIGRoFkCjsYzB1eY_6CWIsHTOIZp_ion68LPMGyONheMaUCanW0tA7FmqK5LF1XT6A&_hsmi=32846075 <comment><USER2> Or we can not look at tech debt as debt but as a unhedged call option:

[http://higherorderlogic.com/2010/07/bad-code-isnt- technical-...](http://higherorderlogic.com/2010/07/bad-code-isnt-technical- debt-its-an-unhedged-call-option/)

From the article:

Call options are a better model than debt for cruddy code (without tests) because they capture the unpredictability of what we do. If I slap in an a feature without cleaning up then I get the benefit immediately, I collect the premium. If I never see that code again, then I'm ahead and, in retrospect, it would have been foolish to have spent time cleaning it up.

On the other hand, if a radical new feature comes in that I have to do, all those quick fixes suddenly become very expensive to work with. Examples I've seen are a big new client that requires a port to a different platform, or a new regulatory requirement that needs a new report. I get equivalent problems if there's a failure I have to interpret and fix just before a deadline, or the team members turn over completely and no-one remembers the tacit knowledge that helps the code make sense. The market has moved away from where I thought it was going to be and my option has been called.

<comment><USER3> Honestly, this seems like a stretched comparison to me. How many managers understand options? And what is even the underlying for your call option? Why would it be a call option and not a put option?

<comment><USER4> That's precisely the point - the reason so many companies fall into the trap of technical debt is that they not only don't understand the risks of what they're getting into; they lack the language (and analogies) to describe the risks.

</comment></comment></comment><comment><USER5> Here's a question: if you have a team and an internal culture that managed to create a legacy code mess in as little as six months in their existing app, how is giving them a microservices architecture and Docker to play with going to help?

If you give that team that structure, it seems to me you're highly unlikely to end up with beautifully bounded context and highly likely to end up with even more of a mess than you started with.

<comment><USER6> "Corgibytes often introduces new clients to Docker, making it much easier and faster to set up new _developer environments._ " (emphasis mine)

She isn't advocating using Docker for the target environment, she is advocating using Docker to set up a standard _development_ environment that allows the developers to be productive[1] in 10 minutes rather than 10 hours.

I've been in the situation where the development environment is a poorly documented, massively multi-step steaming pile. The result is I spent a lot of time chasing down those responsible for the steaming pile (the "rockstar" in the department) asking them how to get the development environment working. Typically they pull the keyboard away from me, type a bunch, and then say "there, it works." Which it does. For a while.

Rinse and repeat for every developer. Regularly.

[1] Well, at least building the system rather than staring at mysterious very broken error messages.

<comment><USER7> Isn't "setting up your environment" pretty much a one time cost, though? In my head at least, losing a couple days up front doesn't matter as much, it's the time _after_ that the needs to be optimized. But maybe that's just my work place where people tend to stay on the same team for years...

<comment><USER8> Shouldn't be.

When you automate "setting up your environment", you are able to switch between several of them, create new ones for forks or extra tests, and roll back to debug production issues.

</comment></comment></comment></comment><comment><USER9> In my experience, diagnosing the tech-debt problem, prescribing the solution, and implementing the solution are not really the hard parts of this - the hard part is battling the culture that led to the problem, and wrangling that huge gulf between "seeming consensus" and "actual consensus" that the group is actually going to change direction by _accepting_ the diagnosis, _adopting_ the solution, and _starting_ work.

Maybe an outside consultancy makes this easier since they are sort of imbued with a moral authority when coming in, but it could also mean that all the hard political work has been done beforehand in agreeing to hire them.

<comment><USER10> I agree. Very often I see this set forth as a problem with management, but it seems to me that other engineers are also a significant part of the problem. I try really, really hard to never be that engineer. If someone sees defects in something I wrote, regardless of the scope, I'm totally fine with whatever they do to make it better, up to and including totally replacing my work.

<comment><USER11> It's the whole system that forms the basis for the problem: management, engineers, PMs, Designers, everyone who touches the problem space. If you want to improve, you need to make sure each part of the system is aligned around the same goal. Sounds hokey, but it is the reality.

That means, as well, that it's both your responsibility and others' responsibility at the same time. Sure, you shouldn't be "that engineer," but you should also realize the kinds of things in the system that make someone become "that engineer," or lead them to be "that engineer" in some situations, or on the positive end, how certain engineers avoid it altogether. Then try to reproduce those factors and spread them.

The problem is never individual. It's never about a good coder or a bad coder or anything like that. There are always multiple internal and external factors.

</comment></comment></comment><comment><USER12> I can't agree with this enough idea enough. Also I just love refactoring.

Most of my side work is contributing to existing projects, but here's the stats for 3 school projects: 20,896 lines deleted for 30,342 written. 2 of the projects had fixed requirements from the beginning though one was a more free- form independent study. Additionally all 3 had only one additional author and I did a majority of the line additions and deletions.

I'm pretty sure these numbers are way untypical for this sort of work---with fix goals and deadlines with no more than a few months per project I assume most people delete pretty little, and basically only during debugging.

Certainly this refactor-happy approach did cause some missed deadlines early on, and getting all the abstractions correct still means basic functionality often doesn't come together until the last minute. But I still that the immense technical wealth does pay off as I get _more_ productive the longer I maintain the project---the abstractions anticipate the sort of extensions I may later wish to add by laying a firm foundation. And the fact that the functionality does appear last second speaks testifies to the increasing productivity---longer hours or last minute panic doesn't explain it.

I think most managers would be horrified this approach, but if you're a real company planning on being around indefinitely and not some startup just hanging together or student, this method should be all the more fitting.

<comment><USER13> Refactoring is a necessary outcome of poor design choices. It is obvious that in a perfect world with perfectly designed software, you would never refactor right? While I applaud your continued effort at perfection, the goal should be less refactoring not more. Not less refactoring because we don't care about quality, but less refactoring because we get more right from the start.

<comment><USER12> I agree in principle, but here's two big (and heavily opinionated) real-world phenomena that push back:

1\. As a die-hard function programmer believe most everything out there is designed poorly---not because everybody incompetent but because anything working with poorly designed languages and libraries must itself necessary be less well designed. Bad abstractions breed other bad abstractions! To write near-ideal software usual an excise of ripping up the foundations---so a lot of refactoring.

2\. We learn good design best by refactoring. When righting new code, functionality and elegance are competing goals, but when refactoring elegance can be tackled in isolation. Furthermore, refactoring is an opportunity to prove (to oneself and others) that given abstractions indeed make code better. Finally, it's hard to distill good design to principles beyond "don't repeat yourself" and "make bad things impossible", but refactoring offers an opportunity to try things and see what works.

<comment><USER10> It's like we're the same person.

I've found it next to impossible to get it through ( some ) people's thick heads that refactoring is not a sign that something was done wrong the first time around.

>> We learn good design best by refactoring.

Exactly. This is often when the true value of a design pattern becomes crystal clear in an applied ( rather than theoretical ) sense.

<comment><USER12> You mentioned C++, but do you do statically typed functional programming too? Then we are the same person :).

<comment><USER10> I haven't done any statically typed functional programming. I'm interested in some parts of functional programming, mostly as they related to replacing raw logic with functions.

<comment><USER12> Well C++ definitely rewards care and effort in a similar way. Haskell and Rust (to get specific) are good for me cause they allow one to write much more air- tight abstractions, raising the upper limit on what my constant refactoring can yield. No more of that "all abstractions leak" bullshit!

</comment></comment></comment></comment></comment></comment></comment><comment><USER14> I find it amusing they got their inspiration from This Old House.

Between TOH and the head mechanic (also named Bob) at the bike shop I worked at in college, I get most of my work ethic from outside of software, and it shows. I had high hopes for the 'craft' movement in software but haven't seen much of it materialize.

I spent a lot of my formative years watching TOH, including the 'Pay the Piper' episode where two very nauseous homeowners found out their remodel went 2x the original budget. Part of it was scope creep, but there was always a hefty repair because the foundation was being destroyed by a tree or erosion, and a couple times the entire corner of the house (including corner beams) was rotting away from water damage caused by shoddy work on an earlier repair ten years prior.

I am forever looking for badly-sited trees and water infiltration in my code base, and I'm always agitating to throw out bad tools, get better ones, and learn to use them properly. Just like Bob and Bob taught me.

<comment><USER15> I think the "craft of software" is alive and well, it's just weirdly distributed: a few shops doing it throughout, lots of shops (and pretty much all big companies) doing it here or there: an individual coder, a small team, etc.

There are lots of other things like that. Take writing. We all write a bunch of emails (etc.) every day, but how many people try, out of a sense of craft and respect for the language, to write them well?

(Oh and I'm currently having a flat from 1914 renovated, which had additional work done in 1938 and 1958, so I definitely appreciate your analogy.)

<comment><USER14> I also like to make references to how if you're an electrician and the customer asks you to run a wire through a puddle or through the plumbing, you can tell them to politely go fuck themselves because it's not up to code.

In software we have no safety regulations and so it's up to you to win that standoff on your own, and most of us don't have the stomach for that confrontation, so we cave and agree to really stupid stuff all the time. And we know that even if we say no, they'll find some other developer who will say yes.

</comment></comment></comment><comment><USER16> I really wanted to like this post. It's well written. With passion. Using a common metaphor (a house). And about the biggest elephant in the I.T. room today.

But I couldn't. Because it just skated on the surface of the iceberg.

OP is right. Technical debt is a huge problem that requires significant mind shift to address. And I can't find a single thing here that I'd disagree with.

There's a lot of academic theory and cheer leading here. And true, it's requisite to any further discussion. But what I would love to see are specific prescriptions:

      How do you train to avoid the sins of the past?
      How do you enhance process (peer review, QA)?
      How do you conduct post-mortems to organize the attack?
      How do you decide what to black box and what to rewrite?
      How do you prioritize shoring up the foundation and keeping the lights on?
      How do you find tools to automate the process?
      How do you make technology decisions to set the new path?

And probably most of all:

      How do you fix the broken data supporting all this bad code?

Because any treatment of code without diving deeply into the underlying data structure is too myoptic to be of much value.

I've estimated that half of the bad legacy code I've ever encountered would never have even been written if the data were properly structured in the first place. This isn't a discussion of DBMS technology, but a comprehensive treatment of how the business operates and how it's supporting data must be structured, regardless of technology. Fix the data and the code becomes a much more manageable problem to attack.

Of course, maybe OP just didn't get that far.

Nice article. I'd love to read the sequel, about 5 levels deeper.

<comment><USER17> That's motivation for me to write the book. :)

This article was written for more of a CEO audience, which is why it's not as technical. You might like the podcast I did on Hanselminutes. It gets into more technical stuff than I did on First Round. [http://hanselminutes.com/539/learning-to-love-legacy-code- wi...](http://hanselminutes.com/539/learning-to-love-legacy-code-with-andrea- goulet-from-corgibytes)

<comment><USER16> I look forward to that book! (Although I'm not really sure I would classify anything I mentioned as "technical". I think it's all "CIO-discussable".)

Welcome to Hacker News, Andrea, and thanks for making such a nice contribution on your first day. If your motivation ever ebbs, just let me know. :-)

</comment></comment></comment><comment><USER18> Sounds like the word "debt" is being used to make their clients feel guilty, and the word "remodeling" is being introduced to make it sound as if they're doing something novel.

Doesn't technical debt just reflect operational priority? How is having old code a problem if it all works? Debating priority is not the same as automatically asserting it as a problem.

And isn't technical wealth building always an opportunity? Why must one be in debt? But every business has a laundry list of opportunities. Technical wealth doesn't need to be at the top always.

If the axiom is that being cutting edge is sacrosanct, then technical wealth would always be top priority, and technical debt would be an operational problem. But technical debt is just a function of the technical advancement in the field. No matter what you do, you'll always end up in debt if you sit around long enough, and decide to call what you have "debt".

If you can make what you have better with technology available today, do it. If not, leave it. And ignore whether a technology is new or old. Just confirm if it is proven and tested.

<comment><USER19> Technical debt isn't about old vs. new technology. It's about making technically questionable decisions for the sake of reducing development time and costs.

<comment><USER18> Right. Except that's just one of the many ways it's defined in the article. The article is a hot mess.

Even then, from a business perspective, reducing costs can be completely intentional and pragmatic. Meaning it can be profitable, so debt really is the wrong word. It's closer to sacrifice, or even frugality. You could go as far as to say it's technical efficiency, granted it does what is expected of it.

But if it breaks or starts causing problems, then you just have problems. At which point call it whatever you like.

<comment><USER19> > Meaning it can be profitable, so debt really is the wrong word.

The reason why it's called debt is because you'll have to pay it later, with interest.

<comment><USER18> Which is not how the term is being used in the article. But also "technically questionable decisions for the sake of reducing development time and costs" does not automatically become debt. Technically questionable decisions happen regardless so debt can be incurred without intending to save any money, and reducing development time and cost can be done without questionable decisions so without incurring any debt.

The article uses Docker as an example of "remodeling" which could very well be a technically questionable decision, because their argument for it is that it saves a lot of money (and is not a technical argument, which is why it could be technically questionable).

So in a sense, they're actively promoting technical debt because they're choosing their tools based on cost. They should rename their method from "remodeling" to "debt restructuring" or "refinancing". Of course, the middleman always gets paid.

<comment><USER19> > does not automatically become debt.

It becomes technical debt. Just like financial debt costs you the interest rate times the amount owed, technical debt costs you time and resources spent on refactoring and cleaning up the code, rather than on activities that directly increase revenue, say, adding new features.

One thing that makes technical debt particularly problematic is that you can incur in it without knowing it. Unlike the case with financial debt, where it's impossible to "accidentally" borrow money. But, just because technical debt is hard to measure, it doesn't mean it doesn't exist.

> reducing development time and cost can be done without questionable > decisions so without incurring any debt.

In principle, yes. In practice, the most common way to reduce development costs, at least in the short term, is to incur in technical debt.

> They should rename their method from "remodeling" to "debt restructuring" or > "refinancing". Of course, the middleman always gets paid.

No disagreement here.

<comment><USER20> > One thing that makes technical debt particularly problematic is that you can > incur in it without knowing it. Unlike the case with financial debt, where > it's impossible to "accidentally" borrow money.

Debt doesn't occur only because of agreements to borrow, it can occur because you've incurred a liability by some other means. Which, yes, _can_ occur accidentally.

Indeed, cutting development corners arguably risks incurring technical debt that will manifest concretely later in a process much more like cutting physical construction corners might risk negligence liability down the road and less like deliberate, planned debt financing vs. paying cash upfront for construction.

<comment><USER19> Good point. I hadn't considered that possibility.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER21> The thing is that most projects fail for reasons other than technical debt. Not having clear requirements to begin with is one, and running out of money along the way is another big one. There's not much programmers can do about those, and burning time working on tech debt may actually hurt you on the second one.

Rather than thinking of it like a house you have to _live_ in, I think of a healthy codebase more like a busy police precinct. It may be a bit messy, but that's just because there's always something more important to do than tidy up.

<comment><USER22> What you say is correct, but to add to the analogy- if the precinct is such a mess that the officers are constantly tripping over stuff, and criminals are going free because they are misplacing evidence, it is probably time to do some cleaning and organizing!

<comment><USER21> Absolutely. But there is a baseline level of messiness that's acceptable and that's what I'm trying to convey (unlike a house [unless you have kids]).

</comment></comment></comment><comment><USER10> Interesting perspective.

With respect to technical debt reflecting organizational problems:

I've always been surprised at how much internal resistance (management and other programmers) I've faced when trying to pay down or eliminate technical debt, regardless of whether it was my code or other people's code. ( For the record, I've written plenty of bad code in my day. )

In the past when I was foolish enough to try and be deferential, I was given excuses like 'yeah, we don't want that kind of churn in version control' and 'we have to maintain compatibility' even when compatibility isn't an issue at all. This, more than anything taught me that it's better to seek forgiveness than permission.

Love the concept of building technical wealth. That's a great way to put it.

</comment><comment><USER23> I just saw a great term on a friend's Facebook today... "refracturing". That's when you fix bugs by introducing new bugs.

<comment><USER24> Not appropriate for every environment, but I've heard "refucktering" used to describe this.

<comment><USER25> "Refuctor Your Cukes" was a thing a few years ago, I think by Gary Bernhardt, but I can't find it now.

</comment></comment></comment><comment><USER26> There will always be technical debt because of Software Gravity([http://brianknapp.me/software- gravity/](http://brianknapp.me/software-gravity/)) and the Katamari Damacy Effect([http://brianknapp.me/katamari-damacy- effect/](http://brianknapp.me/katamari-damacy-effect/)). Both drive the natural Evolution of Software([http://devblog.procore.com/dev/evolution-of- software-applica...](http://devblog.procore.com/dev/evolution-of-software- applications.html))

<comment><USER10> Yes, and systems that one might refer to as 'disruptive' often get traction because they don't have the same gravitational pull as the incumbent. Maybe magnetism is a better term because feature richness often correlates with complexity, and that can attract and repel people.

</comment></comment><comment><USER27> It was interesting. Too bad the company profiled doesn't really value the developers--if you look at their careers page, they pay 110k for lead devs, and 90k for senior devs: [http://corgibytes.com/careers/](http://corgibytes.com/careers/) . I respect them for stating it up front and I know they are 100% remote, but those salaries seem a bit low to me.

But that's just ad hominem. I think working code is almost never worth a rewrite. See "Things you should never do, part 1" for an old chestnut on the same topic: [http://www.joelonsoftware.com/articles/fog0000000069.html](http://www.joelonsoftware.com/articles/fog0000000069.html)

</comment><comment><USER28> I looked at the careers page on Corgibytes out of curiosity. Their hiring approach is very refreshing.

<comment><USER29> > _We noticed that men constantly asked for WAY more than women when applying, > so we decided to take the salary negotiations off the table to make it > easier for everyone._ [0]

So I'm being punished because some people don't ask for what they're worth? I would consider applying for the senior position but it's less than I make now. This policy means I have to either 1) take a pay cut; 2) punch above my weight and apply for the next rung up the ladder; 3) not apply.

I get what they're trying to do but this does not seem to be a way to go about it while continuing to get the best applicants possible.

[0] [http://corgibytes.com/careers/](http://corgibytes.com/careers/)

<comment><USER28> They hire remote and those salaries are competitive outside of the Bay Area.

I do agree however that their reasoning is a little off putting.

<comment><USER30> I don't think they are competitive outside the Bay area for the roles they are filling. <Anecdote> A year and a half ago I was looking for (and found) a senior/lead remote position. I had four offers from such places as Ann Arbor, Boston, Austin, and D.C. The lowest offer was 20% more than what Corgibytes offers to Leads (plus non-trival equity).

<comment><USER28> That is good to hear. I haven't been captive in over 10 years and I am located in a smaller town so I am a little out of the loop on what senior dev salaries are in most places. Great to hear that remote senior dev positions are demanding that.

</comment></comment></comment></comment></comment><comment><USER31> I really take issue with this chart: [http://s3.amazonaws.com/marquee-test- akiaisur2rgicbmpehea/H4...](http://s3.amazonaws.com/marquee-test- akiaisur2rgicbmpehea/H4y9x4gQj61G9aK4v8Kp_Screen%20Shot%202016-08-11%20at%209.16.38%20AM.png)

In what world are old text messages or Twitter posts better technical artifacts than commit messages or tests? The latter are directly tied to the code expression, include a clear history, and are easily discoverable when looking for the source of an issue or the explanation.

This is so wrong that I'm wondering if I'm reading the chart incorrectly.

</comment><comment><USER32> _" Break monolithic apps into micro-services that are lighter weight and more easily maintained."_

Does anyone has any actual evidence to support this blanket claim, especially the "more easily maintained" part of the claim? My experience is quite the opposite. More separate processes communicating over unreliable network links there are, higher the likelihood of failures and mysterious performance issues. More succinctly, complexity of system goes as N^2 where N is the number of processes communicating over unreliable links (note, my use of the word "unreliable" is very intentional here).

</comment><comment><USER33> Code is not an asset, is a liability. Code that you own you need to maintain.

There's only so much code that you can realistically own and maintain. If you are smart, you will seek ways of owning strictly what you need, which is the code closer to the core of your business.

If there is code that you need and is not close to the core of your business and does not provide a competitive advantage, open source it.

The worse code always comes from lack of visibility and accountability. Open source promotes visibility and accountability and keeps things working and clean.

A culture of accountability and strong technical skills attracts talent and keeps the company competitive.

</comment><comment><USER34> All these articles are fine and dandy but I would like to see more pragmatic articles on how to reduce technical debt. A lot of books have been written aroumd software patterns, service orientation, micro services, etc but none of them really address how to minimize technical debt over the life of software. Also not covered properly is what accounts for texhnical debt? For example, I have fee classes that have good unit tests, interfaces, proper seperation of concerns but performs really bad with 1000 concurrent users. So this goes back to how do we accurately define technical debt?

</comment><comment><USER35> This is a very good article, and I can certainly relate to the points made about legacy code. The problem I had was to be able to quantify the fact that productivity of the programming team was going downhill (legacy code, little to no tests) and be able to make a case to management. I felt like the canari in the coal mine.

Another key revelation from this article was that there are 'Makers' and 'Menders' ... At heart I think I am a maker, but sometimes need to be a mender by necessity and this has a huge impact on my 'happiness' levels.

</comment><comment><USER36> "No thanks I don't want to learn more" on the spam pop-up to close it.

Of course I want to learn more. Not on this site though. Using a guilt trip way to close a pop-up made me exit the site immediately.

</comment><comment><USER37> This analogy works quite well. Basically, you have to look at all of the costs of the current edifice. Maybe it costs nothing on paper to keep the ramshackle old house the way it is, but the impression it gives to visitors is a cost. Likewise, if you think of new hires as "visitors" was well. On the other hand, a building that's well designed can have a positive effect on the public perception of an organization and the mental state of the people working within it. The same thing goes for code.

</comment><comment><USER38> This slogan sounds like a platitude, but might be important.

> Stop thinking about your software as a project. Start thinking about it as a > house you will live in for a long time.

I say it "sounds like a platitude" because experienced software engineers already think this way instinctively. But we still call software development jiobs _projects_ , like the building of a house rather than as an ongoing activity.

Perhaps we should change that language.

</comment><comment><USER39> Looks like something worth forwarding to the non-technical guy as "food for thought".

</comment><comment><USER40> Defining legacy code as code without tests? First time I hear that.

</comment><comment><USER41> Not wealth - assets.

</comment><comment><USER42> Why "forget technical debt?" A better title is probably simple, "How to Build Technical Wealth," the fact that a large part of this article is actually re- hashing the problems of technical debt notwithstanding.

</comment><comment><USER43> How about: "How to avoid technical debt" as a title? It seems like the argument's main premise about building technical wealth is avoiding technical debt....

duh?

<comment><USER23> It's a marketing term. It's rebranding refactoring/cleanup as "technical wealth", which sounds good compared to the "technical debt" companies are tolerating.

There's nothing wrong with good marketing if it's leading to a solution for both parties involved.

<comment><USER44> Programmers are often logical people who neglect the importance of PR. Convincing people and marketing good solutions to them for reasons they don't necessarily understand is a powerful tool.

</comment></comment></comment><comment><USER45> _> Technical debt always reflects an operations problem_

This is a clueless statement. Technical debt is just like any other debt. It's about getting product out fast during a phase where market-share build is crucial, building a dominant position, and then repaying the debt from the much larger resultant revenues, later. This is a critical aspect of the microeconomics of any business relying on network effects. You have to be good (enough), but really you have to be first (ish), and technical debt helps you be first.

Therefore, technical debt, just like financial debt, is absolutely not an operations problem. That's why we have COOs and CFOs whose roles are mainly orthogonal. It's fundamentally a question of strategy of the business.

<comment><USER9> This is easily acceptable as true but practically it seems so easy to abuse since there isn't any real data or standard underneath it in terms of when it starts to make sense to pay off.

No one really knows from the outset what level of techdebt is necessary to succeed, and if the techdebt appears costless (since, unlike the metaphor of paying off financial debt, the interest payments feel relatively invisible), you're always going to have people counseling risk and that it's better strategy to move forward as "fast as possible" right up until your younger faster competitors pass you by.

I don't have clear ideas either on when it's a good idea to pay off techdebt, to me it generally seems to be a good idea to aim on "as soon as humanly possible".

If people get too aggressive on solving tech debt then it turns into gold plating - creating tech that anticipates too much and then gets discarded when anticipations prove false. This is relatively easy to recognize when it happens and is a good indication that you're going too far. Up until that point, though...

<comment><USER45> I disagree that the interest costs of technical debt feel invisible. I personally feel a very heavy burden when cutting technical corners / coding to specifics rather than the elegant generic cases. Indeed I spend a large amount of time in meetings persuading non-tech people of the impact of their (often technical-debt unaware) instincts. If you are in an organisation which is unable to measure, even in broad terms, the impact of technical debt, then that organisation is probably not run by the kind of people who should be managing a tech business. It's why most successful startups in the past 10 years have been run by people who understand code.

<comment><USER9> Yeah, I totally agree with you when we're making the distinction between tech and nontech people judging the techdebt.</comment></comment></comment></comment>


The Roomba's Ancestor: The Cybernetic Tortoise - <AUTHOR> https://spectrum.ieee.org/tech-history/space-age/meet-roombas-ancestor-cybernetic-tortoise <comment><USER2> Not sure how these robot experiments are related to the cybernetic tortoises.

The Johns Hopkins Beast ([https://en.wikipedia.org/wiki/Johns_Hopkins_Beast](https://en.wikipedia.org/wiki/Johns_Hopkins_Beast)) held an almost mythological sway over my imagination when I learned of it in the early 1960's. Lee Hoevel, then a graduate student of Mike Flynn, spoke affectionately of the beast and the noises it made in its nocturnal foraging for electric power sockets on the 2nd floor of the lab where he began his graduate work.

Digging into the pre-history of another experience turned up the following story. Thanks to Bruce Koball who was there.

Briefly, in 1987, Key Dewdney attended the Asilomar Microcomputer Workshop. In conversations with John Wharton and Bruce Koball, he challenged them to come up with a realization of Valentino Braitenberg's thought experiment as described in his monograph "Vehicles: Experiments in Synthetic Psychology" [https://mitpress.mit.edu/books/vehicles](https://mitpress.mit.edu/books/vehicles). The prize was entry to the exclusive First Conference on Artificial Life to be held that fall Los Alamos National Labs. [http://alife.org/conference/alife-1](http://alife.org/conference/alife-1) John and Bruce took up his challenge; Bruce built the h/w (using a gutted radio-controlled model car) and John wrote the firmware. As a "front-end" we used a simple neural net simulation program written for Macintosh called "MacBrain" that Bruce had been experimenting with. It had a nifty GUI which allowed him to define neural net topologies on-screen and then download the net into the vehicle via an async serial port where it was executed in John's code. Their vehicle debuted at A-Life 1 in 1987, and then was shown again at the annual AMW (the Asilomar Microcomputer Workshop) and in Stanford's iconic Colloquium, EE380. Then, at Fred Coury's urging, Bruce wrote a brief paper, "A Test Vehicle for Braitenberg Control Structures", on our efforts for COMPCON Spring 1988. [https://www.researchgate.net/publication/3496636_A_test_vehi...](https://www.researchgate.net/publication/3496636_A_test_vehicle_for_Braitenberg_control_structures) [Bruce R. Koball, Motion West, Berkeley; email@example.com, email@example.com]

I, Dennis Allison, was an observer and not a participant in both these anecdotes. It was inspiring to see Bratenburg vehicles ([https://en.wikipedia.org/wiki/Braitenberg_vehicle](https://en.wikipedia.org/wiki/Braitenberg_vehicle)), designed as a thought experiment, actually demonstrate very complex behaviors even though the control program used a very simple rule set. John released several vehicles during the RATS session at the annual Asilomar Microcomputer Workshop where they scurried about under tables and chairs. Some hid, others vamped. They were an immediate hit, a showstopper with an audience of jaded techies. It took a while to find them all as some went into deep hiding mode. Later, John repeated the release as part of an EE380 Colloquium talk at Stanford, but Terman Auditorium lacked the hiding spaces Asilomar provided.</comment>


Avian tree of life required 400 years of CPU time - <AUTHOR> http://www.sciencemag.org/content/346/6215/1320.full

<comment><AUTHOR> Here are a couple of non-technical summaries:

[http://www.aaas.org/news/new-genome-sequences-reveal-bird- tr...](http://www.aaas.org/news/new-genome-sequences-reveal-bird-tree-life)

[http://www.bloomberg.com/news/2014-12-11/an-unprecedented- fl...](http://www.bloomberg.com/news/2014-12-11/an-unprecedented-flock-of- genomes-redraws-the-bird-tree-of-life.html)

[http://news.nationalgeographic.com/news/2014/12/141211-bird-...](http://news.nationalgeographic.com/news/2014/12/141211-bird- crocodile-dinosaur-genome-evolution-science/)</comment>


Why you should use Continuous Integration and Continuous Deployment - <AUTHOR> http://blog.teamtreehouse.com/use-continuous-integration-continuous-deployment

<comment><USER2> Great post. I could not agree more. To further the article, CI/CD are often neglected by small teams / startups. However, startups would benefit more than large teams (as a percent of time) by automating the build and deploy processes.

The only point I've heard a counter to is "Automate Rollback". Noah Sussman (previously of Etsy) mentioned that they never rolled back (at a Groupinar). When a bug was pushed to production, they would fix in dev, test, and deploy. If I remember correctly, he mentioned their time to fix was < 7 mins (or better).

Also, when I first started in my career, one of our most senior admins stated something very similar. In a meeting, I suggested we have a rollback mechanism. The response was that code is like a river, keep it moving in one direction.

In practice, I've found that rollbacks should be reserved for catastrophic events where you are literally running your deployment software to reset infrastructure, dependencies and application code.

<comment><USER3> Came here to say the same thing. You can't roll back without rolling back your database, but I've yet to see a good way to accomplish that. What happens to the data you collected since your last backup? How much downtime do you need for the db rollback?

Also, when you do your rollback, what happens to?:

\- data in caches like memcached or redis

\- images on S3/etc whose URLs are stored in the database

\- session cookies on users' browsers

\- state you've created on systems you integrate with, e.g. fulfillment, warehouses, email lists, . . .

The database is only a portion of your app's "state", and if you suddenly wrench it out of sync with the other systems, you're going to cause problems.

If you absolutely need to stop the world while you develop & deploy a fix, then have an "unavailable" message you can quickly drop in for a few minutes.

Maybe you'll find a bug that really does require restoring to a backup, but that should be rare and will cause a lot of pain, so making this automated seems very scary. You want to do your restore in a controlled, considered way, so you don't cause even more data mangling than you've already got.

</comment></comment><comment><USER4> "Code rots. It should always run somewhere."

Words of wisdom.</comment>


Chinese Python: Translating a programming language (2008) - <AUTHOR> http://reganmian.net/blog/2008/11/21/chinese-python-translating-a-programming-language/

<comment><USER2> Very interesting.

When I lived in Brazil, I discovered that all the graphic designers I knew ran Photoshop in English, instead of Portuguese.

It seemed so odd. Why? Well, it turns out that most menu or interface commands aren't "normal" language at all -- the meaning of "layer" or "unsharp" or "spherize", or the difference between "image size" and "canvas size" \-- so many of these are domain-specific, or Photoshop-specific, and won't make a lot of sense to any regular English speaker at all.

And since so many tutorials, etc., are all in English, it just makes sense to use Photoshop in English. Otherwise, you pull up the Portuguese menu and try to guess how "image size" and "canvas size" might have been translated, and it's just a huge headache.

I'd become fluent in Portuguese myself, my OS was in Portuguese, my browser was in Portuguese... but when I opened up Photoshop in Portuguese, they were right -- I was totally lost.

So while it's _possible_ to translate programming languages, I'm not sure it's actually beneficial too. (Although it certainly makes sense for variables to have "local" names.)

</comment><comment><USER3> Very cool! :-) I found it interesting how the surrounding red boxes around variable names made them each stand out clearly, where separation was, etc.</comment>


Let Matchpad assist you in finding a roommate - <AUTHOR> http://matchpad.co/
<comment><AUTHOR> Looking to find a new place to live with the right people? MatchPad helps you find exactly where you want to live and identify roommates you'd actually get along with.</comment>


DNSSEC Outage on www.cloudflare.com – 2019-03-21 - <AUTHOR> https://ianix.com/pub/dnssec-outages/20190321-www.cloudflare.com/ <comment><USER2> This blip was caused by configuration changes we made to our marketing site (www), which is distinct from any control plane (api/dash) or edge services provided to our customers.

Specifically, we were breaking out our "www" subdomain as a separately managed zone, and some of the configuration wasn't properly migrated.

This resolution failure was regrettable, but there was no impact to the service we provide for our customers.

</comment><comment><USER3> Somewhere tptacek is in tears, and laughing.

<comment><USER4> [https://twitter.com/tqbf/status/1116112320567087104](https://twitter.com/tqbf/status/1116112320567087104)

</comment></comment><comment><USER5> We really need to push back against centralization on a small number of providers. As we have seen with previous Cloudflare issues and the big Dyn incident, a single issue can basically make the internet unusable.

<comment><USER6> I'm also really worried about that. (It's just a feeling but..) for a service as big as Cloudflare I think it may be not as failure proof and clustered designed as it should be for a massive DNS provider.

I for myself pay for a smaller DNS provider like CloudDNS with a bigger redundancy in NS servers (4 instead of 2 at Cloudflare) than going for free at Cloudflare.

<comment><USER7> Cloudflare is one control plane, but it's 1) anycast 2) over 100 locations 3) multiple servers per site. The SPOF with Cloudflare is either your account getting hacked, or (much less likely) a CF control plane/configuration outage.

Someone could probably build a better DNS provider than Cloudflare, at least for their specific site, but it would be difficult. I don't know of any other DNS provider I'd consider more robust, particularly against high load, DoS, etc.

(Disclaimer: worked for Cloudflare 2014-2016)

<comment><USER8> This is rather weird claim. Getting your account hacked is the least of your worries, when every single thing is maintained by a single organization, a single team, on a single autonomous system, with lots of reliance on single hardware and software components. This is basically three nines level stuff, with hours of downtime per year on average. It's relatively easy to do better than that with do-it-yourself CDN using DNS-routed multiple independent hosting providers for edge nodes, getting to four, five nines level. (and DNS separately is not worth talking about, because it has built in redundancy, anything will always be more reliable than a centralized DNS provider)

<comment><USER9> > with lots of reliance on single hardware and software components

Are your saying you have inside knowledge and that's the architecture? (I'm guessing no)

<comment><USER10> I've never seen any company use completely different software or hardware for each redundant instance of a service, so it's a pretty good bet CloudFlare isn't doing this either.

<comment><USER11> That would imply a SPOF. One component of any kind that can take down the whole thing. The only such "component" I can think of is a human, not a technical one.

<comment><USER8> I meant single kind of component, not one thing handling everything.

If you use juniper routers, for example, a juniper specific software, hardware problem or a mistaken assumption about juniper specifics could take down all routers and an entire network.

<comment><USER11> Usually any kind of such issue wouldn't take out _every_ component of a type unless user error is involved. Like deploying the wrong policy to all devices. Which again comes back to humans being the weakest link. I can't really imagine a particular hardware problem that would kill _all_ components at once. This being said I probably didn't experience all possible problems so far :).

<comment><USER10> Sure, humans are the weakest link, who cares? Regardless of the cause of the failure, catastrophic cascades are more likely if the systems and operations involved are homogeneous. That's why evolution prefers diversity.

<comment><USER11> _Natural_ evolution. Because it follows vastly different rules. I still fail to see any example given for how one "cascade failure" takes down all the routers in an infrastructure like Cloudflare's. I can think of a dozen ways a non-homogeneous system can fail (like incompatible updates and config, confusions between the types of components, etc.). In the end you usually end up with massive expenditure that introduces just as many problems as it solves.

You may be onto something that nobody else spotted but so far the arguments are too generic ("failure") or incompatible with the premise (rules of natural evolution applied to very artificial systems).

Don't get me wrong, I'm happy to learn something new and understand a different point of view but so far the arguments don't help me.

<comment><USER8> I actually used that example because they had this exact problem in the past, here's the link: [https://blog.cloudflare.com/todays-outage-post- mortem-82515/](https://blog.cloudflare.com/todays-outage-post-mortem-82515/)

<comment><USER10> And Google had a similar issue recently where they didn't test their firmware upgrade auto rollback, so a boned firmware upgrade bricked a region until they could manually recover it. If they had rolled out to all regions at once, _and_ all the devices were the same, it would have been chaos.

Often the only thing preventing mass upgrades from becoming mass outages is some part of the network just happens to work differently.

<comment><USER11> Well... sure. Just as long as you keep in mind that a "not really tested [something]" will very easily get replicated on multiple vendor devices. It's not like they did it because they hate Vendor1 but will make sure to test all the corner cases with Vendor2. Some scenarios will by design ensure you can't have all of them fail because they are not susceptible to the same failure modes. But to compensate you introduce additional failure modes (especially human error) by using a heterogeneous environment. Not to mention the expense.

I was actually hoping for an interesting human independent failure. A cosmic radiation caused bit flip that would occur on a particular device. :) Human error can overcome any setup.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER12> "why should a DS record for www.cloudflare.com matter?!" \- that was my exact question when I looked at the output from the DNSSEC Debugger.

Now I'm curious as to why www has NS records...

(DS records are used to tie DNSKEYs to a child zone from the parent zone).

<comment><USER2> It has NS records because that's how the owner of cloudflare.com (within the Cloudflare Dashboard) delegates control of www.cloudflare.com to another team.

<comment><USER12> Ah. That makes a lot of sense, thanks.

</comment></comment></comment><comment><USER13> The title gives the impression that this was an outage of Cloudflare's DNSSEC service, whereas in reality the Cloudflare website was down due to a DNSSEC error. Ideally the title should be clarified to make it obvious that Cloudflare customers were not affected.

</comment><comment><USER14> time doesn't match exactly but that might be it: [https://www.cloudflarestatus.com/incidents/3k7gtg4fml1p](https://www.cloudflarestatus.com/incidents/3k7gtg4fml1p) ([https://www.cloudflarestatus.com/history](https://www.cloudflarestatus.com/history) for the list)

</comment><comment><USER15> The Cloudflare Android 22.214.171.124 VPN app was down most of the day.</comment>


Google Analytics Premium – $150k / yr - <AUTHOR> http://www.google.com/analytics/premium/index.html

<comment><USER2> Enterprise pricing is an entirely different league from individual or SMB pricing. The only thing surprising here is that they're displaying the price openly, whereas most SaaS companies have you speak with a sales team first ("Contact Us").

With that said, I think it's funny that the customer testimonial at the top of the page is about a basic feature that's available in the free Analytics:

> "Google Analytics shows us how our customer segments behave on mobile vs. > desktop. That's a huge plus as we make key marketing and product decisions."

<comment><USER3> It does seem surprising that they list $150k / yr- obviously this not typical SMB pricing or anything mass market. Although it is not new- definitely seen it before (sorry I can't reference). I think your funny point raises a good question though- what is the value here? The price point is not insignificant, at all. They list 1 billion hits per month as a capability... does this strategy surround scale (which is not an unusual SaaS strategy) where small clients get the tech free and big ones pay- or is there something special here that the masses do not see, like keyword "not provided" data?

<comment><USER2> I imagine the benefits are more along the lines of: More computing power (for reports of large data-sets), special API access, phone support, insurance, data security, etc.</comment></comment></comment>


Pentagon Announces New Strategy for Cyberwarfare - <AUTHOR> http://www.nytimes.com/2015/04/24/us/politics/pentagon-announces-new-cyberwarfare-strategy.html

<comment><USER2> I have very mixed feelings about this. It would be a poor decision to not have very strong defensive capabilities and offensive capability also to deter adversaries.

But (but!) my country (USA) has been beating the drums of war too loudly for decades and under Bush and Obama the situation in my opinion has gotten worse. I believe that the security interests of the USA are well served by paying closer attention to relationships with other countries and this does not include bullying. Moving military bases and capabilities up to Russia's borders is the most recent activity that concerns me.

This may be too simple of an explanation but is probably mostly true anyway: there is just too much money to be made in the war industry and it warps our news coverage and geopolitical strategies.</comment>


Real-life Iron Man - Raytheon XOS2 Exoskeleton - <AUTHOR> http://www.wired.com/video/security/security/9525752001/reallife-iron-man-raytheon-xos-2-exoskeleton/619226616001

<comment><USER2> Yeah, not so much Iron Man, it's more Ripley in Aliens, with her loading dock suit - "Get away from her you BITCH!"</comment>


Screen scraping: How to profit from your rival's data - <AUTHOR> http://www.bbc.co.uk/news/technology-23988890

<comment><USER2> Curious to know how many engineering teams are still using IP blocking and rate limiting as their primary vector for mitigating this type of activity?</comment>


Some Practical Thoughts on Suicide - <AUTHOR> http://fourhourworkweek.com/2015/05/06/how-to-commit-suicide/ <comment><USER2> I think the point about analyzing the impact of your death on other people is extremely crucial.

Finding an external motivating force is essential to making it out of a depression situation. You need to draw your mind's attention away from yourself and your problems.

Social service is also something that works well - not only does it keep you busy, you often come into contact with people who have far more severe challenges in life than you. That's some valuable perspective when you're contemplating suicide.</comment>


How 20 Popular Websites Looked When They Launched  - <AUTHOR> http://www.telegraph.co.uk/technology/6125914/How-20-popular-websites-looked-when-they-launched.html

<comment><USER2> the linked page is blog spam. The content is taken from an earlier Daily Telegraph article without attribution:

[http://www.telegraph.co.uk/technology/6125914/How-20-popular...](http://www.telegraph.co.uk/technology/6125914/How-20-popular- websites-looked-when-they-launched.html)

</comment><comment><USER3> I've seen earlier screenshots of Amazon.com than that one. [http://www.telco2.net/blog/images/amazon%20early%20screen%20...](http://www.telco2.net/blog/images/amazon%20early%20screen%20shot%20nov%202009.jpg)

<comment><USER4> I was also suspicious of the Amazon homepage. I seem to recall that they didn't even sell music until after they purchased CDNow.

</comment></comment><comment><USER5> Most of these (e.g. Twitter, Flickr) are inaccurate since they're simply using the Wayback Machine which often misses css and images, completely changing the appearance.

</comment><comment><USER6> Wikipedia strongly reminded me of WikiWikiWeb, <http://c2.com/cgi/wiki?WelcomeVisitors>. I actually kind of prefer this sparser look, at least for things that don't have a strong visual aspect.

</comment><comment><USER7> Aside from the inspiration via how quickly knocked together some of these look, it's interesting to see early directions that have since been abandoned, eg: YouTube's dating site style "I am a $gender looking for $gender" drop- down.

</comment><comment><USER8> I would say that Amazon and Drudge look the most "recognizable" between then and now (with Google a close 3rd).

I wonder if that's simply because they haven't done a major pivot like many of the others.

</comment><comment><USER9> The design for Twitter that launched in 2006 looks pretty ugly. I am sure there were better designs in 2006. It looks like 1995.

<comment><USER10> Twitter wasn't even called Twitter when it launched; it was twttr, and it had a pretty hideous logo: <http://www.flickr.com/photos/factoryjoe/190576959/>

</comment></comment><comment><USER11> This reinforces Reid Hoffman's maxim that if you're not embarrassed when you launch version 1, you spent too much time on it.

</comment><comment><USER12> Amazon hasn't changed much.

<comment><USER13> craigslist hasn't changed much either, it is still ugly. BBC looked good though.

</comment></comment><comment><USER14> Ha ha ha - Amazon hasn't changed! They're still stuck in 1995 UI / UX.

<comment><USER3> They have ([http://www.telco2.net/blog/images/amazon%20early%20screen%20...](http://www.telco2.net/blog/images/amazon%20early%20screen%20shot%20nov%202009.jpg)) but once they found something that worked well it makes sense they'd stick with it. A pretty design that causes a 1% drop in sales would be pretty stupid, and I'm sure they've A/B tested such things.

</comment></comment><comment><USER15> Damnit. I want an eMate 300 now.</comment>


Business Model Canvas for User Experience - <AUTHOR> http://grasshopperherder.com/business-model-canvas-for-user-experience/ <comment><USER2> As usual Tristan makes me think... about refactoring Alexander Osterwalder's Business Model Canvas, making it more UX Grokkable.

</comment><comment><USER3> I think this is a significant improvement of the Business Model Canvas for startups. I believe that the final visual language will look more like a custom drawn directed graph (more like a data flow diagram) rather than a table with boxes.

</comment><comment><USER4> This new perspective on the BMC makes total sense, it aligns the planing process to start with the client in mind (which, by the way, we sheldom forget to do).</comment>


45 Out of 50 Electronics Companies Illegally Void Warranties After Independent R - <AUTHOR> https://motherboard.vice.com/en_us/article/9k7mby/45-out-of-50-electronics-companies-illegally-void-warranties-after-independent-repair-sting-operation-finds <comment><USER2> Could a farm tractor be considered and electronic device?</comment>


More Women Than Men Are Obese in America, and Gap Is Widening (2015) - <AUTHOR> http://www.npr.org/sections/thesalt/2015/11/13/455883665/cdc-more-women-than-men-are-obese-in-america-and-gap-is-widening <comment><USER2> Here's the main hack:

Do not eat anything that contains sugar.

To start off, try it for just 1 week. You will realize that sugar _is_ a drug to our brain.

Once you are clean, reduce the "hidden sugar", carbs, to a minimum, and increase vegetables to reach 60% of the volume of your food.

You'll feel great again.

<comment><USER3> I was totally off sugar for a while. My diet shifted to consist mostly of meat. Unfortunately, my cholesterol shot up like anything.

Eating vegetarian, or white meat that's quick is very hard to do without sugar. I eat Soylent, and it's super sugary, but easy to consume. On the other hand, I've tried a bunch of protein bars / powders, and literally none of them are savory.

But, yeah, I agree with you, I would kill for an easy, pure vegetable diet.

<comment><USER4> There are low-carb alternatives to Soylent.

Keto Chow is the one I use. I definitely prefer the taste of Keto Chow to Soylent. It's more like a milk shake. Also, Soylent gave me consistent acid reflux. [https://www.thebairs.net/product- category/ketochow/](https://www.thebairs.net/product-category/ketochow/)

<comment><USER3> Ah, but these flavours all still seem sweet. Once I have sweetness on my palate, I find it difficult to abstain from sugar.

</comment></comment></comment></comment><comment><USER5> As much as I don't want to excuse or allow obesity, or that the advice in this thread is extremely applicable in reducing the rates of obesity, I will say that fat loss for women is indeed harder.

This video[1] explains in greater detail, but essentially all of the hormonal changes a woman goes through on a month-to-month basis can have drastic effects on their ability to lose fat, to keep up performance while exercising, as well as water/nutrient absorption on a week-to-week basis.

These changes do not happen to men, and they are additional considerations when a woman needs to lose weight. Not that they aren't insurmountable, or that the topic itself isn't for more advanced athletes, but we can generalize this to say that it is more difficult for women, so I'm not surprised that the gap would widen given those additional constraints.

[1] [https://www.youtube.com/watch?v=6846ZTBu08k](https://www.youtube.com/watch?v=6846ZTBu08k)

</comment><comment><USER6> Women on average are not always the most obese ones. In some countries like Norway, Switzerland, Canada, and Italy, it's the men who have the higher obesity rates.

Interesting to note that Mexican, Turkish, and especially South African women are quite a bit more obese than the men.

OECD publishes a lot of stats in this area:

[http://www.oecd.org/health/Obesity- Update-2014.pdf](http://www.oecd.org/health/Obesity-Update-2014.pdf)

Could it be cultural differences? In the countries where the men are more obese, the average obesity rate is much lower.

</comment><comment><USER7> Women has naturally higher body fat percentage, plus pregnancy and then menopause are both big hormonal shocks that induce weight gain, so this is hardly suprising.

<comment><USER8> The study doesn't say they have more body fat. That we already know since woman are biologically prepared to do so.

The study says that more woman are obese: I.E.: Looking at healthy body fat in the two genders (where the healthy body fat levels for woman are already higher then men), more woman are above those levels.

<comment><USER9> Women may be more predisposed to put on fat more easily, because bearing and (even more) nursing a baby both add an enormous amount to a woman's energy needs. Even today, when food isn't scarce, many women lose their "baby weight" and more while nursing.

Secondly, with less testosterone, women put on and maintain muscle with less ease than men. Since muscle burns more resting calories than fat, women must restrict their calorie intake more strictly than men do - even at the same weight and activity level - if they want not to gain.

<comment><USER8> Ok, again: That is already accounted for when you talk about the healthy body fat levels for each gender. The study is about people that go above these levels.

<comment><USER10> I think the point he's trying to make is that while the natural level may vary between genders and be accounted for, they very likely didn't account for ease of weight gain.

<comment><USER8> Why should they account for the "ease of weight gain"? The study is about unhealthy fat levels, not if you easily gain more fat or not.

The study conclusion is simple: Obesity in men stabilized, obesity in woman is increasing.

</comment></comment></comment></comment></comment></comment><comment><USER11> Guess we can't have the cake and eat it too. Or perhaps if we do we need to go for a triathlon. Seriously though, I wonder how much of this is correlated with our sitting problem, back problems, knee problems that result from a sedentary + high calorie lifestyle. Stop looking at going to the gym to be like <insert god-like body reference here> and just get out for a freaking walk, do some pushups occasionally, maybe a few sit-ups. Even small steps can improve overall fitness. But yeah....probably a good IoT biz opportunity.

<comment><USER12> I recently learned about a product that clips to your shirt near your neck and vibrates when your posture is bad. I'd love to see more devices that don't just track your fitness, but remind you constantly in subtle ways like that. I know smartphone notifications don't work for me.

<comment><USER2> Or you could learn to live what is often called "mindfully", by practicing mindful meditation.

This has the benefit of increasing the quality of your life _overall_ (besides the fact that you don't need to spend money for that).

</comment></comment></comment><comment><USER13> Quite a while ago, I worked for a bit in Norway. Almost everyone there seemed fit. When I commented on it, my coworkers said it was kind of an in-joke that Americans came in two types. There's a small minority of younger fitness junkies, who often look _unhealthily_ thin, and then a much larger number of people who are distinctly overweight. I've never seen anything to contradict that "bimodal distribution" idea. It's one reason that I take diet or exercise advice based on what worked for one guy in his twenties with a _huge_ grain of salt (heh). Come back when you're forty, and we'll talk. Better yet, let's try looking at large-scale peer-reviewed studies of what works and what doesn't _across ages and genders_ , instead of spreading anecdotes and flimsy theories.

</comment><comment><USER14> Well, it's going to be either women or men, and it's going to be either growing or shrinking.

</comment><comment><USER15> There is a recent movement in America that can be neutrally summarized as obesity prescriptivism. (I won't use the language either of its proponents or critics. By the way, I am super-proud of everyone in this thread as of the time I'm posting - though it's only 9:30 AM East coast, 6:30 West Coast on a Sunday, so that the quality of responses might drop soon. Let's do our best to keep it high.)

My recommendation is to be able to opt out, for example via a smart phone setting that shows that an individual has opted out of obesity prescriptivism. As a practical matter, for example this may allow them to be shown menus with 500-1100 calorie entrees (or less), whereas obesity prescriptivism would require that such choices not be shown. I'm careful not to use the language of either side. These are the facts of the current situation.

</comment><comment><USER16> It would be so cool to have a high tax on sugar (and saturated fat). It has at least as much damaging effect as weed. I know it's not the perfect solution but it would force companies who want to sell in shops to decrease using it.

<comment><USER17>
      >It would be so cool to have a high tax on sugar

To some degree we have that, with tariffs on sugar coming into the US, which raises the price high enough that everyone uses alternatives.

<comment><USER18> Well, having a tax on one form of sugar while subsidizing another (HFCS) means that in practice, you have a sugar subsidy that makes it economic to add bad calories because it's cheap.

</comment></comment></comment><comment><USER19> We put more pressure on women to diet, and most dietary advice is horse crap. If your diet consists of "low fat" garbage, and a bunch of fruits/grains... you _will_ wind up fat. If more men were lost to the "weight loss" industry, I'm sure they'd be equally as obese.

<comment><USER20> Every time I look at the US food pyramid I'm blown away by what an obvious unhealthy scam it is. 6 to 11 servings per day from processed grain products? I don't think so.

The agriculture department should not be in charge of US nutritional guidelines.

</comment></comment><comment><USER21> Isn't the issue the huge numbers of people who are obese, not their gender.

<comment><USER22> Sure, but for understanding any issue, looking at demographics is helpful.

Once we see that in some countries one gender is more likely to be obese we can look for reasons. If we're lucky there's something that causes women to become obese that we can eliminate.

<comment><USER19> ...and that thing is almost certainly "Diet food"

</comment></comment></comment><comment><USER23> This article is from November. Why bring this up now?

Anwyays,

> After decades of increases, obesity rates do seem to be flattening out.

> And another note of optimism: The CDC finds childhood obesity has leveled > off. In many states, as we've reported, obesity rates are falling among > preschool-aged kids.

Good. Maybe in a few years we'll see a drop?

> Across all adult age groups, about 38 percent of women are obese, while 34 > percent of men were obese.

4% seems like a pretty small gap.

> And, the divide becomes even greater for some women of color. The obesity > rate among African-American women is 57 percent and 46 percent among > Hispanic women.

I'm assuming that Asians were the exception? Is it because of genetics? Or income-level?

<comment><USER22> >> Across all adult age groups, about 38 percent of women are obese, while 34 percent of men were obese.

>4% seems like a pretty small gap.

It's just 4 percentage points, but a different way to phrase it is that women are 10% more likely to be obese than men. That's not a gigantic gap, but it's still quite significant.</comment></comment>


"How do I opt out of Google Location services?" - <AUTHOR> https://support.google.com/nexus/answer/1725632#how_opt_out <comment><USER2> Now just add _optput to opt out of wifi sense too and we're done. I guess.</comment>


Shigeru Miyamoto of Nintendo Expands His Empire - <AUTHOR> http://www.nytimes.com/2008/05/25/arts/television/25schi.html

<comment><USER2> > Nintendo does not disclose Mr. Miyamoto's compensation, but it appears that > he has not joined the ranks of the superrich.

apparently he doesn't ask for much money

> According to Mr. Miyamoto, gameplay systems and mechanics have always come > first, while the characters are created and deployed in the service of the > overall design.

this is what i love about his games. he focuses heavily on the mechanics. eg the "tactility" that makes Mario 64 a blast to speedrun. and it's not for the sake of the mechanics -- it's for the sake of the player

i think there is a lot of parallel with what Miyamoto does to usability/interfaces in general, where you have to get into the shoes of your audience and experience their experiences

> "There are very few people in the video game industry who have managed to > succeed time after time at a world-class level, and Miyamoto-san is one of > them."

this is definitely no accident. there is a famous phrase related to Miyamoto: "upending the tea table." where if he's not satisfied with a game he will have large portions of it (maybe all of it) redone

i liken this to the same sort of feeling as rewriting a program -- you have it all in your head, so you can see how it sucks, and how it could be structured better. what makes Miyamoto special is that he can hold the game in his head in the first place

<comment><USER3> > > "There are very few people in the video game industry who have managed to > succeed time after time at a world-class level, and Miyamoto-san is one of > them."

> this is definitely no accident. there is a famous phrase related to > Miyamoto: "upending the tea table." where if he's not satisfied with a game > he will have large portions of it (maybe all of it) redone

And it's no accident that it's so rare: being at liberty to do that kind of thing is a huge luxury in the game industry. The way games would need to be developed for that is to build a playable prototype with a team of less than 5 people, and only when that prototype reaches a Miyamoto-level of addictiveness, should it go into full production. That's generally not how it works. (yet?) Especially not if developer != publisher.

<comment><USER4> I think that's how you should write software in general. Write tiny prototypes that you can rip up and change on a whim, and aim for making something so fun/beautiful/useful that it would become a crime against creativity not to turn it into a "full" product.

If you stumble on a way to repeatably accomplish this, you'll consistently create hit software.</comment></comment></comment>


Show HN: StockPerf – Better stock market investing - <AUTHOR> https://stockperf.com/ <comment><AUTHOR> Hey guys. I wanted to see if I could invest my money in a better way than just sticking it in a Vanguard account. I decided to just try buying a bunch of stocks following a bunch of different investment ideas.

I then made a spreadsheet, dumped all my stock purchases into it, tagged each purchase with a strategy, and then averaged together the return on investment for each purchase within each strategy.

The tool helps you see what's working and what's not, and verify that your stock picking ideas are actually playing out well in the real world.</comment>


American darknet vendor and Costa Rican pharmacist charged - <AUTHOR> https://www.justice.gov/opa/pr/american-darknet-vendor-and-costa-rican-pharmacist-charged-narcotics-and-money-laundering <comment><USER2> Justice is such a poor way to describe what is happening here. I have full empathy with those who have struggled with opioid addiction or lost loved ones to the disease. But the fact is that opioid prescriptions are still being written with too little oversight, too few safeguards, and not enough support for patients. Withstanding such contradiction in treatment of opioid suppliers, the federal government cannot keep treating opioid abuse on the supply side. We need solutions that focus on patient health and wellness. An opioid on its own does not result in overdoses or abuse, and even moderate use can be balanced with a healthy lifestyle. The DOJ does not have the tools, skills, or experience necessary to address the public health crisis that is opioid abuse.

<comment><USER3> Opioids are among the best medications for treating severe pain. If we're focusing on patients I'd much rather focus on rehabilitative strategies since the current degree of increased scrutiny is already making accessing adequate medication more difficult for groups like the elderly or people with chronic pain. Even more increased oversight is just going to escalate hesitation among doctors.

<comment><USER4> I wonder where most of the harm is coming from with opioids. Do the opioids themselves cause more harm than society does by making them illegal?

The cases I've mostly heard about seemed to be that people hot addicted to opioids and the only way to keep it going was to break the law. That eventually got them in trouble. For some drugs it does seem like the government trying to protect you from the drugs do more harm than what the drugs themselves do. Are opioids among them?

<comment><USER5> Prof Nutt made and published a universal harm scale which accounts for multi dimensional harm of drugs, and potentially allows comparisons to be made between them [https://www.ncbi.nlm.nih.gov/pmc/articles/PMC6109763/#B29](https://www.ncbi.nlm.nih.gov/pmc/articles/PMC6109763/#B29). This work got him sacked from his lead advisory role to the UK govt, as it undermined the policy and caused embarrassment. Nutt still works in Imperial College researching psychedelics as novel therapeutics. The money shot is this [https://www.researchgate.net/figure/Overall-weighted- scores-...](https://www.researchgate.net/figure/Overall-weighted-scores-for- each-of-the-drugs-The-coloured-bars-indicate-the-part-scores_fig1_47635105)

A recent article which contextualises the work is here [https://www.ncbi.nlm.nih.gov/pmc/articles/PMC6109763/](https://www.ncbi.nlm.nih.gov/pmc/articles/PMC6109763/)

<comment><USER6> Wow this is awesome. I've pondered the need for exactly this sort of thing for a while as the obvious desired basis for drug policy. Shouldn't be surprised the Nutt has done it!

Obviously it's lossy to reduce something with this much complexity down to a single dimension but it's still a helpful tool nonetheless.

</comment></comment></comment></comment></comment><comment><USER7> >"These charges are a warning to drug traffickers worldwide that neither the shroud of the darknet or of virtual currency can hide their illegal activities from the vigilance of U.S. law enforcement," said Acting U.S. Attorney Michael Sherwin for the District of Columbia.

The real warning to heed here is that we allow some countries to arrest citizens of other countries who committed crimes outside of their borders.

I know what extradition is, but the concept of spending your whole life in country A, and having country B decide it's time to arrest you and charge you within their jurisdiction makes me uncomfortable. I think more people will oppose it once global power balances start to shift this century.

<comment><USER8> This is already starting to happen.

A bunch of countries suspended extradition to Hong Kong after all the recent power consolidation by China because while they trusted an independent Hong Kong to have reasonable limits on its judiciary they do not trust China to do the same; after all this is a country that dismisses "rule of law". And in fact the whole protest situation was caused by Hong Kong's Government introducing a poorly worded extradition bill that would've essentially given carte blanche for Chinese extradition. [https://www.nytimes.com/2019/06/10/world/asia/hong-kong- extr...](https://www.nytimes.com/2019/06/10/world/asia/hong-kong-extradition- bill.html)

<comment><USER9> And the reason for the initial bill was due to a Hong Kong citizen murdering his girlfriend in Taiwan.

Taiwan and Hong Kong do not have extradition treaties.

The murderer is still free in Hong Kong.

<comment><USER8> I mean this was never going to happen anyways because cross-strait relations are fickle and perilous at the best of times, and Taiwan has specifically said that it does not really want to participate in extradition with HK after the whole fiasco. [https://www.nytimes.com/2019/06/15/world/asia/hong-kong- murd...](https://www.nytimes.com/2019/06/15/world/asia/hong-kong-murder- taiwan-extradition.html)

The rational response to "hey the country who originally requested the extradition doesn't want to do it anymore" would be to shelve the bill, but at that point the Government and CCP wanted to save face and dug in their heels. Which makes the whole situation an extremely stupid case study of how not to de-escalate a situation.

</comment></comment></comment></comment><comment><USER10> A victimless crime - unless you think we should be locking up all of the alcohol sellers? Alcohol addiction is a sad, sad affair.

I would rather someone be addicted to pharmaceutical grade opioids than street heroin laced with fentanyl and other junk.

<comment><USER11> > I would rather someone be addicted to pharmaceutical grade opioids than > street heroin laced with fentanyl and other junk.

The two addictions are more or less the same. Someone addicted to street heroin can substitute pharmaceutical grade opioids. Someone addicted to pharmaceutical grade opioids can substitute street heroin. This is largely a class discrepancy, as the higher tolerance a person has the more expensive the pharmaceutical grade opioid use is compared to street heroin.

<comment><USER10> I don't believe I commit any crime when I put any substance of my choice into my own body, regardless of what the state says.

<comment><USER12> Right!?! Legalizing drugs would solve a lot of issues and let people actually address and talk about the real problems which is often mental health, however there are a lot of things like mushrooms and LSD that may cause people to "wake up" and not want to be a slave to the system anymore and I think that is mostly what they fear. People realizing they have more choice and power than they've been led to believe.

</comment></comment></comment></comment><comment><USER13> I see Silkroad mentioned, so I'm assuming these were crimes committed years ago?

23,900 bitcoin? That was a big business. No wonder why they were targeted.

<comment> fbi-director If it truly was at the time of the original silkroad, you have to consider the change in value of btc since then to get a more realistic idea of the size and value of their business. Not saying it wasn't big, no idea, just stating we should consider that fact.

<comment><USER14> 2013 - 2018, per indictment

</comment></comment></comment><comment><USER15> There's so many questions left unanswered from this indictment. How did they get his emails, how did they get the bitcoin amount. I'm more interested in the details and opsec failures.

</comment><comment><USER16> It's 2020 and if you are still against legalization, or at least decriminalization, you are the enemy.

It's no longer incumbent on anyone else to explain to you why the drug war is immoral, prejudiced, and stupid. Violence is exploding all over the country and homicide clearance rates are at an all time low. The irony of what these fat, beer-swilling thugs at the "Department of Justice" and DEA are doing will not be lost on history.

<comment><USER17> Legalization of what though? Opioids? The drug that kills tens of thousands of people in the US each year, which is almost immediately and very strongly addictive, and with which it is extremely easy to overdose? No thanks. That'd be extremely damaging to society, and it'd inevitably kill a bunch of people and affect an order of magnitude more through network effects.

<comment><USER18> Look at the reason why people use drugs. I am convinced happy people with fulfilling lives don't get addicted.

Large scale substance abuse is IMO an indication something went very wrong in society.

<comment><USER19> > I am convinced happy people with fulfilling lives don't get addicted.

Even if that were true, it would still be possible that it was true because the same innate features which incline toward addiction work against having a happy fulfilled life in the same external conditions that someone without those features would have a happy, fulfilled life.

</comment></comment></comment></comment><comment> ur-whale It'll be interesting to see if the DOJ manages to confiscate the crypto this time around, and if so how.

<comment><USER20> I'm fairly naive about the details of BTC, but couldnt the network decide to either 1) quarantine those blocks/addresses or 2) Agree to a signature that assigns the value to another wallet?

<comment><USER21> The problem here (by design) is jurisdiction, the US DOJ doesn't stretch as far as the bitcoin network.

As an example, why would someone in Russia stop processing coins because the US DOJ said so?

Virtual currencies aren't the battleground for the US's war on drugs.

<comment><USER22> ... because any wallet downstream of the tainted wallet in the transaction graph could be considered tainted as well. This would be a highly effective attack on Bitcoin as an illegal payment method - the onus would be on every Bitcoin user to ensure that they have provably done everything they could to avoid obtaining "illegal bitcoins".

Therefore, the person in Russia in your example would have an interest in not dealing with tainted coins, because they couldn't be sold for the same price anymore.

It would basically split Bitcoin into white (provably legit), grey (unsure) and black (illegal) coins.

Yes, this would probably also destroy Bitcoin, but that's a mechanism by which states could obtain extraterritorial power over what people do with Bitcoin.

<comment><USER20> This is almost exactly the concept i was thinking of. If the exchanges want to continue to do business in the US they will blocklist the FBI's "suspect" wallets / blocks or something like that...</comment></comment></comment></comment></comment>


FeFETs: How this new memory stacks up against existing non-volatile memory - <AUTHOR> http://semiengineering.com/what-are-fefets/ <comment><USER2> A link to the paper mentioned in the article (paywall/institution access): [http://ieeexplore.ieee.org/document/7838397/](http://ieeexplore.ieee.org/document/7838397/)

TL;DR - Much lower erase time than NOR Flash (3 orders of magnitude), 1/3 voltage required for write/erase, all other parameters typically the same

The results from the paper are summarized as follows:

\- Cell size is comparable to current NOR Flash (0.045 um^2)

\- Endurance is also comparable (~10^5 cycles)

\- Estimated 10 year retention @105C, compared to 150C for NOR

\- Read time <25 ns, versus <10 ns

\- Write time around 500 ns (1/2 of NOR)

\- Erase time around 500 ns, compared with 10^6 ns for NOR (!)

\- Energy consumption not yet measured, but claimed less than Flash

\- Max voltage of 4.5V, versus 12V for Flash

<comment><USER3> You forgot the most important stuff: it scales well with various technology nodes and processes, requires much less mask layers than flash and it is much more cost effective.

Edit:also , they mentioned an ncfet transistor for general use.since this transistor remember his state, you may not have to power it in sleep mode(whole circuit or partial), and thus could get zero leakage current!

<comment><USER4> > _Edit:also , they mentioned an ncfet transistor for general use.since this > transistor remember his state, you may not have to power it in sleep > mode(whole circuit or partial), and thus could get zero leakage current!_

Um, no, that's not the point of the NC FET. The "negative capacitance" aspect of the ferroelectric material means that the NC FET can switch on or off faster, reducing power wasted in the switching process, and therefore allow chips to run cooler.

See [https://phys.org/news/2011-09-ferroelectrics-pave-ultra- low-...](https://phys.org/news/2011-09-ferroelectrics-pave-ultra-low- power.html) for a general explanation or [https://www2.eecs.berkeley.edu/Pubs/TechRpts/2015/EECS-2015-...](https://www2.eecs.berkeley.edu/Pubs/TechRpts/2015/EECS-2015-171.pdf) for a technical explanation.

<comment><USER3> In [1] , they build a non-volatile flip-flop out of a ncfet.

[1]section 5.3 , [https://www.google.co.il/url?sa=t&source=web&rct=j&url=http:...](https://www.google.co.il/url?sa=t&source=web&rct=j&url=http://nics.ee.tsinghua.edu.cn/people/lixq/resources/SRC_TechCON2015-NCFET.pdf&ved=0ahUKEwi3jeK_tJbSAhVLAcAKHZbUCGEQFggvMAQ&usg=AFQjCNES_qLrdDN0XglEDFQCb08emPU2aQ&sig2=-P1AEDalQHR3V8XsyPHXRA)

</comment></comment></comment></comment><comment><USER5> "First and foremost, FMC is aiming at the embedded NVM space."

It also seems that they compare it with NOR and not with NAND, which again points to the scenarios where not much is stored and not often rewritten. Then _it 's not a technology for SSD's or USB sticks, how I understand it_, but it's to allow to have a single chip which has both the logic and the re- writable firmware. And they claim it's cheaper to achieve that than with the competing technologies.

</comment><comment><USER6> This stuff is fascinating, especially the challenges in fabrication as the theoretical limits are approached. I do have a question, if an expert could help explain. The article says,

"With FMC's proprietary hafnium oxide, the standard gate dielectric can be made ferroelectric—even for film thicknesses that compare to the one used in standard logic transistors. This proprietary hafnium oxide integrates extremely well with all current and future processes utilizing HKMG. Therefore, a scalable ferroelectric FET finally becomes possible."

What is proprietary about the hafnium oxide? Is it the process of creating it, or the molecule itself?

<comment><USER4> If I understand it correctly, it is the process of depositing the HfO2 onto the wafer in a way that it retains its ferroelectric properties and is compatible with other chipmaking processes that is proprietary. Depositing it improperly would result in defects at the junction between the HfO2 and the underlying gate that would render the FeFET nonfunctional.

<comment><USER7> When I was in semiconductor manufacturing, we tried using a hafnium oxide layer in the capacitor dielectric for our DRAM. It did not go well, if I recall correctly (10 years back). Not for design reasons -- we were using it for its dielectric properties, not its ferromagnetic ones -- but for process reasons. It was hell on the diffusion furnaces. Flakes everywhere, wafers sticking. Lots of angry morning meetings.

</comment></comment></comment><comment><USER8> Sounds like an improvement over FRAM, which is already a shipping product that you can buy today - albeit more expensive than Flash and not as dense.

The ability to build with standard HKMG (high-k metal gate) wafer processing (unlike Flash) is very handy - means FeFET memory can be incorporated into high-speed microcontrollers.</comment>


RISC-V CPU is not vulnerable to Meltdown and Spectre - <AUTHOR> http://www.tomshardware.com/news/risc-v-not-vulnerable-meltdown-spectre-cpu-bugs,36231.html <comment><USER2> Which RISC-V implementations uses speculative execution?</comment>