Show HN: Who runs this – A Chrome extension that shows who runs a site - <AUTHOR> https://chrome.google.com/webstore/detail/who-runs-this/jfccjdbjpkmppcpdogdfbgillpaakmgn <comment><USER2> Would be nice to note that it sends hostnames of the sites you visit in plaintext, no SSL/TLS, across the internet to:

      http://api.corpwatch.org/companies
      http://18.104.22.168:9119

<comment><USER3> Nice catch. 104.236/16 is DigitalOcean, so best guess would be some kind of server belonging to the author.

<comment><AUTHOR> It is mine, yea.

<comment><USER4> I think it is better if you mask your server ip using some service like CloudFlare and assign it a domain name when making public apps with links to your server.

</comment></comment></comment></comment><comment><USER4> Is that a private key to connect to your server in your repo? [https://github.com/kaolti/Who-Runs- This/blob/master/key.pem](https://github.com/kaolti/Who-Runs- This/blob/master/key.pem)

<comment><AUTHOR> Hehe, was for the Chrome store, got rid of it now.

<comment><USER4> [deleted]

<comment><USER5> Did you just publically admit to attempting to break into his server?

<comment><USER4> not really.

</comment></comment></comment></comment></comment><comment><USER6> What would be even more useful would be a "that's surprising!" button next to the result.

When an owner is often reported as surprising for a domain, the extension should either blink or directly display the owner without being clicked.

<comment><AUTHOR> That's awesome, add that to the todos.

</comment></comment><comment><USER7> Hmm. It can't tell me that thewaytohappiness.org is run by Scientology.

But expecting it to see through Scientology front groups is perhaps asking too much. ^^

</comment><comment><USER8> Very cool idea. I noticed it reports that ridiculousfish.com "is run by" namecheap, but namecheap is only the registrar and does not run or even host the site.

<comment><AUTHOR> Thanks! Yea, the problem is the registrant organization of the domain is set to Namecheap. Not sure how to get around domain privacy for now.

<comment><USER9> Maybe the extension could check the info on the SSL certificates (if available) if the domain is registered through a proxy?

<comment><USER10> This is almost necessary for the extension to be useful. A good number of domains I checked are all "run" by WHOISGUARD, INC.

<comment><AUTHOR> Hm, do SSL certificates have information about the owner?

<comment><USER10> I think only Extended Validation (EV) certificates have this info by default :(

</comment></comment></comment></comment></comment></comment><comment><AUTHOR> Thanks for all the feedback guys! Took it down for now and will republish when it's fixed.

</comment><comment><AUTHOR> May have a couple of bugs but one use case would be finding out that rottentomatoes.com is run by Comcast.

</comment><comment><USER9> When run against www.ssa.gov it says "something seems to be wrong" LOL

<comment><USER7> For .gov domains it might as well just show "The Government of the United States".

<comment><USER11> That's not exclusively true anymore. For example, New York City has nyc.gov .

</comment></comment></comment><comment><USER12> Could you share a link to the repo if its available? Very cool idea!

<comment><AUTHOR> Thanks! Here it is: [https://github.com/kaolti/Who-Runs- This.git](https://github.com/kaolti/Who-Runs-This.git)

<comment><USER13> This appears to be a private key (so no one should ever be able to read this file): [https://github.com/kaolti/Who-Runs- This/blob/master/key.pem](https://github.com/kaolti/Who-Runs- This/blob/master/key.pem)

Is this for publishing to the chrome app store? If it is, I recommend taking down the extension and republishing with a new secure key ASAP.

<comment><AUTHOR> lol, saved my ass it looks like! Took your advice.

<comment><USER14> It is still in the commit history. You need to throw that key away and get a new one.

<comment><USER13> Exactly, that key is now completely compromised (it was the second it was public). You can still see it here: [https://github.com/kaolti/Who-Runs- This/commit/764945d8d968b...](https://github.com/kaolti/Who-Runs- This/commit/764945d8d968b29008f7d7075f014a8624830b07)

You will need to generate a new key and resign with the new one.

</comment></comment></comment></comment></comment></comment><comment><USER15> When ran against my own domain (diegorbaquero.com) it just shows "Something seems to be wrong"

<comment><AUTHOR> Yea, it doesn't check for registrant name atm, should probably show that, if there's no registrant org.

</comment></comment><comment><USER16> Link is broken</comment>


M.2 - <AUTHOR> https://en.wikipedia.org/wiki/M.2 <comment><USER2> I just installed one of these in my new workstation, really crazy fast.

<comment><USER3> It should be noted that M.2 is simply the form factor, not the bus. There are SATA III M.2 SSD drives like the Samsung EVO 850 that are no faster than normal (~500mb/s sequential). You want an NVME SSD like the EVO 970 which gets >3000mb/s.

<comment><USER4> There are poor M.2s. However it's not SATA vs NVME which is to small a difference to measure in most cases. SATA SSDs can easily hit 1.5GB (b as in byte) per sec.

NVMEs have a small advantage at higher queue depths I believe (not typical of desktop workloads). But all the benchmarks I've seen put the difference so small that it's hard to tell if it's real or just sampling error.</comment></comment></comment>


3.4 Million Americans are Extreme Commuters (2005) - <AUTHOR> http://www.businessweek.com/magazine/content/05_08/b3921127.htm

<comment><USER2> Below is my personal experience with different job situations:

Between 17 and 20 I never travelled more than a few miles for work. I worked as a server at a resort ($14/hr), as a night auditor at hotel where I had 1 hour of work to do and 8 hours to do it ($8.25/hr) and as an entry-level web developer ($10-15/hr). All of the jobs paid more than I needed and I had ample free time.

The main drawback for these jobs was that I wasn't treated as well as I wanted. With one of the web companies, I happened to see a recent hire's check and saw that he made more than me. I asked the owner why this person made more than me when I had more experience, and her answer was that I made a lot for my age and that the other person had a degree.

From 20-24 years of age I worked as a freelancer, starting at $25/hr and going to $90/hr, billing about 30 hours a week and working about 50. I always worked remotely, and for a year during this period I lived in Hawaii.

The perks of working from home are many. I always lived near the beach and could take beach breaks during the middle of the day. I had a lot more time because I had no commute at all. The main drawback was that I didn't have enough social interaction. I'm still discovering what a huge, negative effect this has had on my life.

These days I make $100/hr, 40 hours a week, and I commute between an hour and half and two hours every day, depending on traffic. I listen to audiobooks on the ride in, but going home they make me too sleepy. Because of the audiobooks, I don't mind the commute as much as I would otherwise. I feel like I learn valuable things during my time in the car.

Also, because I earn more and bill for more hours, I make about twice as much as I did previously. This year I'm planning on traveling around the world, something I've never been able to do. I've also been able to afford a lot of little niceties like improv lessons and snowboarding lessons. I'm very glad that I'm able to buy these experiences.

I'm also trying to make friends with the people I work with. I already consider my immediate colleagues to be good friends and great people, and it makes me very happy to know them and see them every day.

The long-ass commute does get me down sometimes. I'm still trying to figure out how to make more time for my personal projects. With the amount of money I'm making, though, it's feasible that I'll be able to take little vacations just to work on my ideas, something which wasn't possible before. So overall, the long commute is definitely worth it.

<comment><AUTHOR> Thanks for taking the time to write all this.

Question: Is there anything keeping you from living closer to where you work?

<comment><USER3> Not always an option. In my case, moving closer would quadruple my taxes. Decent neighborhoods are 40 minutes away (average commute in my office is about 40 min).

There's also the question of working spouses and kids.

If it were for a boffo CEO position I'd consider moving but, to be just another seat warmer, not so much.

(disclaimer: I really like my job which is why I drive 2 hours each way. If I can work out moving closer that would be beneficial to all involved I would. I won't get within 30 minutes though - that I already know).

<comment><USER4> Quadruple?? If you're talking a state boundary, I think you're probably missing something. Some states have higher income tax, some have higher real estate tax (which you pay for indirectly via rent).

Quadruple your cost of living, I could believe.

EDIT: Additionally, somewhere around 80% of the taxes that you do pay go to the federal gov't -- so it'd be really, really hard for a change in state to quadruple your tax burden.

<comment><USER3> Hyberbole retracted after a little research. I was speaking of property taxes specifically. It's _possible_ to quadruple my property taxes by moving to the same state in which I work. That would put me about an hour from my office and is the most expensive area in the state. Being within 30 min of my office would be 1.5 - 2 times more expensive property tax wise.

</comment></comment></comment></comment></comment><comment><USER5> I think its worthwhile considering the possibility that work is broken.

It's easy to accept the status-quo.

Before the Internet, consumers accepted that there was an inherent trade-off between selection and convenience: you could either have the convenience of the corner store with its limited selection, or the selection of a WalMart if you were willing to take the drive out to their regional supercenter.

The Internet allowed companies like Amazon to deliver both more convenience and more selection. Consumers could have their cake and eat it, too.

Today, most people accept that there is a trade-off between living where you want to live, and working where you want to work.

What if that were not true?

<comment><USER6> I think it's also worth considering that American cities are themselves broken.

Americans driving everywhere (and increasingly driving _further_ everywhere) is a problem larger than just an analysis of where we live and work. I'd love to see a study like this that also factors in how long we're spending to get to stores, restaurants, schools, entertainment, etc.

It's quite likely that the Bus Buddies from the article aren't only burning 15-20 hours a week commuting to work, but more like 25-30 hours a week commuting in general. To the store, to a ball game, to a kid's recital, to a park, to a bike trail, etc.

<comment><USER7> Indeed, broken by design. It's not just a myth that GM/Ford/Oil Companies killed streetcars and public transportation. They really did do their best to create the suburbs/commute/'MUST drive everywhere' layout to benefit their businesses. Unfortunately, it worked.

</comment></comment></comment><comment><USER8> I am one of those extreme commuters, by choice. I spend about 18 hrs/week commuting on public transit. The daily commute includes 15 min walking to the train station (which I love), an express train, a 20-minute bus ride (which I dislike), and buffer time (if you take the train every day, you do not want to stress yourself out running for the train) and (schedule gaps between bus arrival and train departure).

I don't recommend it to anyone but the fact is there are costs and benefits to everything. Sometimes the costs seem to outweigh the benefits of living in the city, but, in all, I think living in the city has made me able to meet people who I connect with. There are times when I am too tired to go out with friends and times when I should be tired because I did go out with friends.

The times (which are more frequent now) when I am heads down in iPhone programming - the train ride goes by quickly, almost too short. Tethering is an absolute requirement. There are many times when I simply rest and leave the MacBook in its case. Lots of time to think and start executing on app ideas.

It all comes down to: what do you benefit from living where you choose to live and working where you choose to work.

<comment><USER9> This brings up how public transit is a LOT different than driving. You have the ability to do other things _safely_ so it's not like it is a total lost in productive time.

</comment></comment><comment><USER10> New thought exercise: add the hours you spend commuting to your "work" hours and calculate your new rate per hour. If your commute is significantly more stressful than your job (metropolitan traffic jams), bill yourself time and a half or more to account for the impact to your health.

</comment><comment><USER11> It is often easier to drive and extra hour each way, then try to move yourself / your family in the current housing and job market.

<comment><USER12> Really? That's 460 hours per year, spent sitting on your ass in traffic. If you worked hourly at $20/hr, that's over $9000/year. If you average 30mph, and it costs 24 cents/mile in depreciation, maintainence, insurance, and gas to operate your vehicle, you're spending over $3300/year on that extra distance.

The equivalent of _thirty days_ of your life not spent with family, training for marathons, writing code, building furniture. What would you give for an extra month of your own time each year?

<comment><USER11> It is not free to move, and it is unlikely that a person in this situation can find work closer to home.

You miss the problem of selling old house, getting new house or (more likely) rental versus low additional payment per week. Maybe you have kids, and the school where you are is better than the one you would move to. Maybe both spouses are working and you had to make that "whose work do we live closer to" decision.

<comment><USER9> You're right it isn't free to move, but what I think their point was is that not many people do the math to see how much it is costing them in money and time. I've done both, but when I was driving an hour each way I never sat down to think of how much it was costing. Normal people probably just don't even think that way, but once you see it on paper it is scary and I think a lot of people would reevaluate things like the cost to move, schools, and your job.

This calculator seems pretty useful: <http://www.commutesolutions.com/howmuch.html>

Lastly, although I can't find a statistic on, you have to think the more miles you drive the higher the risk of dying/getting hurt in a car accident.

<comment><USER11> People often don't have the upfront money to change their situation. It really doesn't matter the final cost, if you can't afford one of the options. You do what you can do.

</comment></comment></comment></comment></comment><comment><USER13> I traded a stressful 50min car commute across a jam packed bridge for a 15min walk. I'm making slightly less money, but my quality of life has gone up dramatically. My wife likes it too.

</comment><comment><USER14> I drive an hour to work b/c there is no reasonably nice and affordable housing with good schools anywhere near where I work.

</comment><comment><USER15> For 5 of the 7 years that I worked full time before doing a startup I had a 1 hour commute. For 4 of those years it was with a train, which I actually kind of missed when it was over. The net result was that I spent 10 hours a week reading books. The amount that I read dropped off sharply after the commute was gone.

</comment><comment><USER16> I'd be interested to see what has happened to these numbers in the past five years - particularly through the great run-up in oil prices that peaked in summer 2008 and the sharp economic crash that followed.

Disclosure: my daily commute is a refreshing 15 minute bike ride.

<comment><USER7> No doubt people with a 3 hour commute suffered with the higher prices and had second thoughts.

Really, considering how wasteful these commutes are in terms of pollution, time and energy expenditure for little gain, it wouldn't be so bad if energy prices rose again and discouraged this behavior.

<comment><USER16> _Stable_ high energy prices would do a great job of discouraging this behaviour, as they've done in Europe. Unfortunately, in North America we're stuck with "an energy policy that encourages consumption" and leads to energy price volatility (with the accompanying economic volatility), coupled with governments that are terrified to do anything that looks like raising people's gas prices.

<comment><USER11> Well, since much of the US was built on cheap energy prices, and no alternative seems to be able to roll out in the next 5 years, all high energy prices will do is cause people to give up other things. Many cities and rural areas have no effective alternatives. Heck, I once consulted at a place in Minneapolis, MN that had no bus stop for miles.

</comment></comment></comment></comment><comment><USER17> Wow - I thought my 50 min. one way commute was bad, but I guess I should be considering myself lucky. For those commuting long distances by car, has anyone figured out how to optimize that time? I usually try to make calls, listen to podcasts, or just take some time to think about projects that I'm working on. I figure that about 50% of my commute is being used productively-- if anyone feels much more efficient than that, I would love to hear strategies...

</comment><comment><USER18> Have the national trends changed since a half-decade ago when the submitted article was published?

I work from home, except that I have contact hours for teaching about a twenty-minute drive from here. We live near a city bike and hiking trail, and walk to much of our shopping and to the public library where I do much of my research.

</comment><comment><USER19> I recently moved and reduced my commute from an hour and twenty minutes (one- way) to about twenty-five.

It has made an incredible difference. I'm much more relaxed, and I feel like I actually have a life during the week again. I'd probably take up to a 20% pay cut to avoid doing it again.

</comment><comment><USER3> I'm one of those extreme commuters too. I work from home two days a week so, I try to look at it like I spend 4-out-of-7 days at home. It helps only a little.

My previous job was 100% telecommuting. That lasted almost five years.

It's better than not working (did that too).

</comment><comment><USER20> I got laid off in January, but I really, really miss my commute. It cleared my mind, woke me up on the way to work, made me feel healthier, and let me blow off some steam on the way home after the really stressful days. It was an hour each way, give or take...

By bicycle. ;)

</comment><comment><USER21> New Paltz is a sweet town, but that bus costs $20 one-way. Doing that everyday adds up to a lot of money very quickly.

</comment><comment><USER22> I wonder if the figures are the same now, after the housing bust.

</comment><comment><USER23> First, I freely admit this is probably not even a meaningful comparison, I'm just gloating.

I'm a student (CS major) at a mediocre school in a tourist city. I live within walking distance of the bar I work at, and school is a 20 min bike ride away.

last week I turned in a file compressing application I wrote in MASM assembly language.

right now I'm high on mushrooms.</comment>


Botan: Crypto and TLS for C++11 - <AUTHOR> https://botan.randombit.net/ <comment><USER2> Security record: [https://botan.randombit.net/security.html](https://botan.randombit.net/security.html)

Also worth considering: [https://tls.mbed.org/](https://tls.mbed.org/) I've used it and it is indeed very easy to use.

</comment><comment><USER3> The API of Botan forces you to use `secure_vector<byte>` to store data to be encrypted or decrypted. That makes it impossible to eliminate unnecessary copying where possible. A huge design mistake.

<comment><USER4> What unnecessary copying are you referring to? According to the documentation, `secure_vector` is just a typedef of `std::vector` with a custom allocator that zeroes memory on destruction.

Also, in C++11, `std::vector` contains the member function `data()` which returns a pointer to the underlying data. The data is mutable through this pointer.

<comment><USER5> It also tries to "mlock" the memory region on Linux so it doesn't get swapped, however it falls back to allowing swapping when it fails.

</comment></comment></comment><comment><USER6> To be noted Boost.ASIO offers integrated SSL support, based on OpenSSL (with the advantages and disadvantages that it brings).</comment>


Bazel – Correct, reproducible, fast builds for everyone - <AUTHOR> http://bazel.io/ <comment><USER2> Working at Google, Blaze is one of the technologies that amazes me most. Any engineer can build any Google product from source on any machine just by invoking a Blaze command. I may not want to build GMail from source (could take a while) but it's awesome to know that I can.

I think this could be hugely useful to very large open source projects (like databases or operating systems) that may be intimidating for contributors to build and test.

<comment><USER3> > Any engineer can build any Google product from source on any machine

A little too optimistic :) You can't build Android, Chrome, ChromeOS, iOS apps, etc. via blaze.

<comment><USER4> When I worked at Google I built a Blaze extension to be able to build Android apps. It worked really well, though I'm not sure how well it was maintained after I left in 2010. Internally at Google, Blaze was extremely customizable, and I hope Bazel too, so one can easily add support for building iOS apps etc.

EDIT #1: I see support for building Objective-C apps is already present in Bazel. EDIT #2: Bazel uses Skylark, a Python-like language, which could be used to implement all sorts of extensions, including the one I was referring to.

<comment><USER5> There's an extension language in bazel named Skylark, which will be familiar to you if you wrote build_defs internally: [http://bazel.io/docs/skylark/concepts.html](http://bazel.io/docs/skylark/concepts.html)

</comment></comment></comment></comment><comment><USER6> I've been burned by so many build tools over the years. I've finally settled (for C/++/asm) on the combination of Make + ccache: I build a _very_ paranoid Makefile that recompiles everything if it feels like anything changes. For instance, every rule that compiles a C/++ file is invoked if _any_ header/inc/template file changes. I let ccache do the precise timestamp/check- sum based analysis. The result is that (for large builds < 10MMLOC) I rarely wait for more than a few hundred milliseconds on incremental, _and_ I have confidence that I never miscompile.

I just wish that I had a high-performance replacement for linking that was cross-platform (deterministic mode for ar), and for non-C/++ flows. Writing a deterministic ar is about 20 lines of C-code, but then I have to bake that into the tool in awkward ways. For generalized flows, I've looked at fabricate.py as a ccache replacement, but the overhead of spinning up the Python VM always nukes performance.

<comment><USER7> > I build a _very_ paranoid Makefile that recompiles everything if it feels > like anything changes.

Do you have some kind of way to verify that your makefile dependencies conform to your source dependencies? Is clang/gcc tracking sufficient for your use case? What about upgrading the compiler itself, does your makefile depend on that? If so, how?

Have you considered tup[0]? Or djb-redo[1]? Both seem infinitely better than Make if you are paranoid. tup even claims to work on Windows, although I have no idea how they do that (or what the slowdown is like). Personally, I'm in the old Unix camp of many-small-executables, non of which goes over 1M statically linked (modern "small"), so it's rarely more than 3 secs to rebuild an executable from scratch.

> (deterministic mode for ar)

Why do you care about ar determinism? Shouldn't it be ld determinism you are worried about?

[0] [http://gittup.org/tup/](http://gittup.org/tup/)

[1] [https://github.com/apenwarr/redo](https://github.com/apenwarr/redo)

<comment><USER6> > Do you have some kind of way to verify that your makefile dependencies > conform to your source dependencies?

Nope. I explicitly use a conservative approximation—this guarantees correctness, over speed. Building everything every time with a clean tree is where I begin; I start optimizing after that.

> Is clang/gcc tracking sufficient for your use case? What about upgrading the > compiler itself, does your makefile depend on that? If so, how?

Self-rewriting Makefiles (to consume the .d files), combined with the cleaning necessary for them, become a large technical debt—especially given the complexity of the Makefile needed to generate them. Modern CCen just aren't capable of this. Perhap Doug Gregor's module system will land in C21/C++21, and we'll see some good, then.

> Have you considered tup[0]? Or djb-redo[1]?

Yes. They are both don't provide significantly better correctness guarantees combined with sufficiently better performance to justify the cost to porting to older Unixen. (This is a consensus opinion at my shop; I, personally, enjoy tup.)

> Why do you care about ar determinism? Shouldn't it be ld determinism you are > worried about?

Determinism let's me cache *.o/a/so/dylib/exe/whatnot without getting false- positives due to time-stamp changes and owner/group permissions in the obj/ar files (see ar(1)). ld is deterministic under all the CCen I use by setting the moral-equivalent of -frandom-seed.

<comment><USER7> Thanks.

> this guarantees correctness, over speed.

Wouldn't "promotes" be a better word? what guarantee do you have?

> Self-rewriting Makefiles (to consume the .d files), combined with the > cleaning necessary for them, become a large technical debt—especially given > the complexity of the Makefile needed to generate them. Modern CCen just > aren't capable of this.

Haven't needed it in a long time, but back when I did generating one for me was all of running the compiler with "-MD" in the compile phase, and including it in the Makefile - no special "make depend" phase, no noticeable slowdown. What technical debt are you ref

> Yes. They are both don't provide significantly better correctness guarantees > combined with sufficiently better performance to justify the cost to porting > to older Unixen.

Interesting. It is my experience that redo (from apenwarr) is trivial to run and use anywhere there's Python and isn't Windows -- it's almost as fast as Make, and it makes correctness guarantees that Make cannot (e.g., .o file replacement is atomic).

<comment><USER6> Maybe... 'prefer'. I'm more confident that a really conservative Makefile will build my code correctly.

My issue with -MD was not that it didn't provide precise (and correct!) dependencies; my issue was that the build system's most mysterious breakages are when modules (and dependencies) are changed. In that case, there are three situations:

1\. Your .d files are out-of-date, and thus your build is broken;

2\. You have to have a policy of "updating the .d files"; or,

3\. Your makefile has to be .d savvy.

The last option is the one I see most often taken, but with rare success.

> it makes correctness guarantees that Make cannot (e.g., .o file replacement > is atomic).

I wish Make wasn't so entrenched.

</comment></comment></comment></comment></comment><comment><USER8> Correct, reproducible, fast builds for everyone _not running Windows_

<comment><USER9> Convince your employer to ship a half decent unix environment with its OS and it will run on windows too. It's mostly a choice by microsoft to ship a half- baked command line interface with its products, you can't blame google for that.

<comment><USER10> By 'half-baked' you mean 'not * nix compatible' command line. Powershell is _amazing_.

<comment><USER11> I'm a Microsoft fanboy and Powershell is bad Python.

How 'bout we meet in the middle and y'all make the changes the Cygwin guys need? And hey, where'd that POSIX subsystem go? Finally got C99 support almost shipped now how 'bout you reverse that other horrible decision, too?

</comment></comment></comment></comment><comment><USER12> This is an open sourcing of Google's internal build tool.

I know it as Blaze, which Bazel is an anagram of. Many files in the source have references to Blaze.

</comment><comment><USER13> Is Google departing from just throwing white papers over the wall and let community figure out the implementation details? blaze white paper was dropped a while ago and there are already two clones in Pants and Buck at Twitter and FB. It would be interesting to see how far off clones are from original implementation.

<comment><USER14> Do you have a link to that white paper? A quick search on their research site doesn't really yield any results.

<comment><USER15> I'm a developer on Bazel, and AFAIK there is no white paper. We definitely don't want to "throw it over the wall," we're going to try to push more and more development into the open over time.

<comment><USER16> There's not a white paper, but there's this series of posts: [http://google- engtools.blogspot.com/2011/06/build-in-cloud-a...](http://google- engtools.blogspot.com/2011/06/build-in-cloud-accessing-source-code.html)

(and an accompanying presentation)

</comment></comment></comment></comment><comment><USER9> Getting rid of the timestamps in jar files is a huge improvement. I really hate it that when I recompile some huge java project I can't run a checksum on the jar to verify that the build is identical to a previous run (or when being dumped into some project that my current source tree is an accurate reflection of what is running in production).

</comment><comment><USER17> I had a bit of a read but I didn't find where it explains (code or doc) how it achieves reproducible builds.

It seems like a stricter, huge make-like harness (in fact it reminds me of the mozilla firefox python build system a bit).

It's not bad by any means, but it seems like to me it doesn't "magically" fix the "be reproducible" problem at all (which is what it seem to claim)

Am I missing something?

<comment><USER18> You are absolutely correct: Bazel by itself does not make your builds reproducible. If a tool calls rand() or bakes the current time into its output, reproducibility goes out of the window.

What Bazel does, however, is to make it possible to run build steps in a sandbox (although the current one is kinda leaky) so that your build is isolated from the environment and thus behaves in the same way on any computer. It also tracks dependencies correctly so that it knows when a specific action needs to be re-run.

This makes it possible to diagnose non-reproducible build steps easily. At Google, the hit rate of our distributed build cache usually floats around 99%, and this would be impossible without reproducible build steps.

<comment><USER19> Does work done by Debian to make Linux packages build reproducibly help Bazel?

[https://wiki.debian.org/ReproducibleBuilds](https://wiki.debian.org/ReproducibleBuilds)

Would Bazel help with the remaining long tail of packages in Debian?

</comment></comment></comment><comment><USER20> Surprisingly, significant parts of the code is not open source. According to this page, [http://bazel.io/docs/governance.html](http://bazel.io/docs/governance.html),

       Is Bazel developed fully in the open?

       Unfortunately not. We have a significant amount of code
       that is not open source; in terms of rules, only ~10% of
       the rules are open source at this point. We did an
       experiment where we marked all changes that crossed the
       internal and external code bases over the course of a few
       weeks, only to discover that a lot of our changes still
       cross both code bases.

<comment><USER21> I don't think you're interpreting that section quite right. That section is talking about whether or not Bazel is fully _developed_ in the open, and the answer is "Unfortunately not".

What they mean is that changes to the internal source of Blaze often involve changes to both the open sourced part, which is Bazel, and the closed parts, which are additional rules that are neither open sourced, nor included in Bazel (Blaze has about 5x as many rules as Bazel).

It's best to make atomic changes, so rather than split the changes, review and submit the open source changes externally, and the closed rules changes internally (which would complicate reviews, testing, syncing and rollbacks), then pull in the external changes, they submit these cross-code-base changes internally, then dump the change into the external repo. The next paragraph on that page makes it clear that the code is open, even if not all of the development process is.

To be clear, all of Bazel is open source and the source is available here: [https://github.com/google/bazel](https://github.com/google/bazel)

<comment><USER22> Can you explain or give an example of a "rule", it's unclear what this means to me.

<comment><USER23> [http://bazel.io/docs/build-ref.html#rules](http://bazel.io/docs/build- ref.html#rules) For example, cc_binary is a rule. Rules are the things that know how to take whatever is specified as it's inputs, do something to them, then produce some specified set of outputs

Google has a large number of rules (IE far far more than just the rules you see in bazel). As part of open sourcing, they have stared out by open sourcing about 10% of those rules.

Some of this is because they are google-entangled. Some of them don't make sense to the open source community. etc

</comment></comment></comment></comment><comment><USER24> What would be needed to get this to work with Haskell?

I read in the "Getting started":

> You can now create your own targets and compose them.

So does this mean it is a replacement for `make`? => Yes

Found the answer here: [http://bazel.io/docs/FAQ.html](http://bazel.io/docs/FAQ.html)

<comment><USER15> If you're interested in adding rules for a new language, check out Skylark: [http://bazel.io/docs/skylark/concepts.html](http://bazel.io/docs/skylark/concepts.html).

</comment></comment><comment><USER25> It's another impressive feat from Google and reading the comments I've kind of established that

1\. Binaries are checked in to source 2\. It's more structured than Gradle 3\. It's for very large code bases 5\. It's _nix only

But...

1\. We've already had the "chuck it in a lib directory" approach. The distributed approach maven/ivy etc seems to be working for the millions of developers out there who just have to get through the end of the day without production going up in flames. I suppose it's like moving a portion maven central into your code base. Checked in. Feels very odd, and kinda against one of the pillars of JVM: Maven. Love it or hate it it's one of most mature build/repository types out there. npm, bower anyone?

2\. Got to agree with astral303. This isn't really something to shout about. Better reproducibility? Gradle/SBT have had incremental builds for quite a while. We all know there's no silver bullet, if you don't declare your inputs and outputs to gradle/blaze tasks or seed with random values then you're only going to get unrepoduceable builds.

3\. Very large, I get that.

4\. Very large code bases tend to enterprise systems. Enterprise systems tend to have a plethora of platforms/OSs so it being _nix only is a drawback. However I suppose that if in charge of 10MLOC code base then I could mandate _nix only builds? However in my experience they also tend to gravitate towards standards that seem to have longevity.

I'm yet to give it a go so I'll reserve final judgement. However I will say that I do wonder how far we'd be if Googles through their brightest minds at and worked with Maven/Gradle/SBT etc to scale their builds. (Yes I realise it's multi-lang - so is gradle). Perhaps the whole community would benefit from performance benefits.

Anyway hats off Google guys. It looks impressive and no doubt I'll jumping all over it in 12 months. In the mean time I'm off to go read up on Angular 2.0, or Typescript or ES6 or ES7 or whatever else I _need* to know to get me through the day.

Really I'm just jealous I don't have 10MLOC code base :D

<comment><USER26> I don't know about Bazel, but Blaze doesn't "check in binaries". Build artifacts are cached, but not "checked in".

The problem with maven and gradle is that their build actions/plugins can have have unobservable side effects.

This approach is more 'pure functional'. You have rules which take inputs, run actions, produce outputs and memoize them. If inputs don't change, then you use memoized outputs and don't run the action.

As long as your actions produce observable side effects in the outputs (and don't produce side effects which are not part of the outputs, but product state which depended upon in some manner), then you can do a lot of optimizations on this graph.

In my experience with maven and gradle, they are way way slower, and that's on relatively small projects

<comment><USER25> Apologies for comment- I'd just gotten home from the pub was drunk :D

I look forward to trying it out. The ObjectiveC rules sound interesting especially given the state of XCode which is a laughable IDE.

</comment></comment></comment><comment><USER27> If i'm sticking to primarily Java; is there a benefit to using Bazel as opposed to Maven / Gradle / Sbt ?

<comment><USER28> At first impression, unless you have a single gigantic source code base, unlikely. From their FAQ:

>> "Gradle: Bazel configuration files are much more structured than Gradle's, letting Bazel understand exactly what each action does. This allows for more parallelism and better reproducibility"

The value of "more parallelism" depends on the complexity of your Java source code base. I can easily imagine why this extra structure can lead to more parallelism.

However, I am not buying "better reproducibility" without justification or explanation. I've had very reproducible Maven builds for years (and I don't see how Gradle would be different). So I would love to know which aspects are improved upon with this structure, if someone could expand or explain.

Finally, I'm very wary of "much more structure". The worst thing about Maven is its extreme insistence on structure and schema and very specific architecture of your build tasks and components. In contrast, with Gradle, you can freely shape your build scripts to reflect the "build architecture" of your source tree in a minimal, maintainable way. Furthermore, when your application's needs change, refactoring your build is far easier in Gradle, thanks to its internal-DSL style (the build script is code).

If the structure isn't "free", you pay for structure with reduced build script development speed. For Google, it's a tradeoff worth having with that massive source tree.

<comment><USER29> I work on Bazel.

We've put a bunch of work into making sure that we know about every file that goes into the Java compilation, and if any of them changes (and only then) do we recompile. Within Google, we use a form of sandboxing to enforce that.

You're also right that it isn't free - we have reason to believe that larger projects and larger teams will see benefits from using Bazel. Use your best judgement.

</comment></comment></comment><comment><USER30> Oh, but my favourite option "blaze menu" is missing :)

<comment><USER31> Huh. I never knew that was there. I'll remember this next time I'm around Charleston.

</comment></comment><comment><USER32> A couple of questions:

* If I have a Maven-based project with heavy reliance on pre-built jars from Maven Central, what's the recipe to port it to Bazel?

* Related, if I have multiple github repos, say a couple open source libraries and a couple private repos, what's a good recipe in conjunction to Bazel?

<comment><USER15> Check out [http://bazel.io/docs/build- encyclopedia.html#maven_jar](http://bazel.io/docs/build- encyclopedia.html#maven_jar). In the root of your build, specify the jars you want from maven and then add them as dependencies in your BUILD files. The first time you run "bazel build", they'll be downloaded and cached from then on. It's somewhat limited in functionality at the moment, but should work for basic "download and depend on a jar".

For multiple Github repos, use [http://bazel.io/docs/build- encyclopedia.html#http_archive](http://bazel.io/docs/build- encyclopedia.html#http_archive) or [http://bazel.io/docs/build- encyclopedia.html#new_http_archiv...](http://bazel.io/docs/build- encyclopedia.html#new_http_archive) (depending on if it's a Bazel repository or not). Let us know if you have any questions or issues!

<comment><USER32> Thanks for the tips. I'm super-hyped that blaze was open sourced, it is one of the best systems I've ever had the pleasure to work with.

A couple more questions :)

* Any pointers for adding Scala (sbt?) support? I'd start here: [http://bazel.io/docs/skylark/rules.html](http://bazel.io/docs/skylark/rules.html).

* Suppose I develop using multiple repos and http_archive. I'd like to make changes both to a library and to a project that depends on it simultaneously, without committing the library patches to master github repo just yet. Is there a way to configure the http_archive, let's say by saying "bazel --mode=local", and have it customize the remote archive http to use a different url (say, my github's fork instead of the master github) for that build?

<comment><USER15> Scala support: yes, add using Skylark. Definitely let us know if you run into any rough edges, Skylark is a work-in-progress.

For multiple repos: there's no command line flag, but you could change the WORKSPACE file to use [http://bazel.io/docs/build- encyclopedia.html#local_repositor...](http://bazel.io/docs/build- encyclopedia.html#local_repository). Unfortunately, this may be of limited use to you. At the moment it's optimized/bugged to assumed that your local repos don't change, so it won't rebuild them (this is great for things like the JDK and gcc, but not so much for actual in-development repos). Feel free to file feature requests for any functionality you need, I'll be working on this a lot over the next couple months.

</comment></comment></comment></comment><comment><USER33> Here's the Gradle Team's perspective on Bazel

[https://www.gradle.org/gradle-team-perspective-on- bazel/](https://www.gradle.org/gradle-team-perspective-on-bazel/)

</comment><comment><USER34> Any reason the python support was ripped out? I've got my suspicions about not wanting/not being able to properly release the python packaging method in use internally, but I'm curious if I'd be tilting at windmills to try and get it to output pexes.

<comment><USER23> I suspect the reason was: "They need to start with something and go from there".

So they started with the use cases likely to be the most popular.

Additionally, there are definitely cases where the implementations of rules at Google are a morass, and rather than dump it on the open source community, it makes more sense to clean them up when they get rebuilt.

</comment></comment><comment><USER26> If only our code search and code review systems were public too.

<comment><USER35> BTW, do you have blaze build for gwt? ant seems unwieldy for me.

<comment><USER26> Internally to google, gwt_application, gwt_module, gwt_test is a built-in rule. GWT itself is built with blaze internally (not ant) as well.

<comment><USER35> Do you have plans to open this stuff?

</comment></comment></comment></comment><comment><USER36> How does it compare with Java 9's sjavac ([http://stackoverflow.com/a/26424760/750563](http://stackoverflow.com/a/26424760/750563))?

EDIT: I fully understand that this is a build tool for multiple languages. But its raison d'etre is speed. So I'm asking what techniques does Bazel use to accelerate builds and how do they differ from those used by sjavac, which is also designed to accelerate builds of huge projects?

<comment><USER37> I work on Bazel.

Bazel also builds other languages, such as C++ and Objective-C.

We do invoke the Java compiler through a wrapper of our own. We think we can make that work as a daemon process to benefit from a hot JVM, but haven't gotten round to that.

<comment><USER38> Any plans on supporting Windows? That will definitely increase the adoption of Bazel.

<comment><USER37> [http://bazel.io/docs/FAQ.html](http://bazel.io/docs/FAQ.html) \- "What about Windows?

We have experimented with a Windows port using MinGW/MSYS, but have no plans to invest in this port right now. Due to its Unix heritage, porting Bazel is significant work. For example, Bazel uses symlinks extensively, which has varying levels of support across Windows versions."

In other words: it's a lot of work, and frankly, our team doesn't know enough about windows to be very good at porting it. We would welcome contributions to make it work on Windows, of course.

<comment><USER39> That would be great. I'm not a Windows user, but having Windows support is a pre-requisite for adoption in many corporate environments, and proper symlinks are available since Windows Vista.

</comment></comment></comment></comment></comment><comment><USER40> Is this the tool that Google uses to build its Golang source? Or is that something else which is not available?

<comment><USER15> The Golang source code for the server code at google is built with this tool. The rules that accomplish this are rather complex due to their interactions with our C++ libraries, and predates the open source "Go" tool. The experience with the Google internal rules, motivated some of the choices in the "go" tool, I believe.

If you're interested, hanwen wrote a bunch rules with similar semantics as the internal rules, see [https://github.com/google/bazel/tree/master/base_workspace/e...](https://github.com/google/bazel/tree/master/base_workspace/examples/go/) .

It would be nice to make these semantics match the external ones better, but it requires us to open up more tooling, so people won't need to write BUILD files.

<comment><USER41> In what cases would using Bazel make sense to build Go projects? If they're extremely large? If they have a lot of dependencies on code in other languages? If you need sophisticated build/release tooling?

BTW, thanks for the release! Will have a fun time digging through this over the next few days. I heard some murmurs that Blaze was going to be open sourced from around the watercooler but didn't think it'd be so soon.

<comment><USER37> I guess if you want to integrate Go tools with builds in other languages. If you are using pure Go for your entire ecosystem, there is not much point in using Bazel, as the "go" tool is very capable for that scenario.

</comment></comment></comment></comment><comment><USER42> _> Why doesn't Google use …? Make, Ninja: These tools give very exact control over what commands get invoked to build files, but it's up to the user to write rules that are correct._

 _> Users interact with Bazel on a higher level. For example, it has built-in rules for "Java test", "C++ binary", and notions such as "target platform" and "host platform". The rules have been battle tested to be foolproof._

But does it give the optional custom level of control that for example CMake + Ninja provide? Or it's only high level rules?

<comment><USER43> [http://bazel.io/docs/skylark/concepts.html](http://bazel.io/docs/skylark/concepts.html)

You can [at least internally] define custom rules to handle pretty much anything, in almost-but-not-quite-python.

</comment></comment><comment><USER44> From the FAQ :

Multi-language support: Bazel supports Java, Objective-C and C++ out of the box, and can be extended to support arbitrary programming languages.

c'mon, not even the Go language from Google itself ?

</comment><comment><USER45> Maven doesn't work so well when there are loads of small self contained 'micro-libraries' (yes, sub-projects, but they are so involved to set up they almost defeat the purpose). Was considering pants -- which doesnt seem like it has great adoption? -- but this seems like its substantially more fully featured.

Presumably will also make opensourcing internal projects easier. That can't be a bad thing :)

<comment><USER46> WRT to Java support: Since it doesn't appear to generate poms or publish to maven repositories it doesn't seem very useful on the open source part of things. It seems explicitly for generating internal, proprietary software from a monolithic source tree. I would have much rather seen the incremental compiler and jar generator integrated to maven than replacing the entire build system.

<comment><USER47> Actually Maven 3.3 was released recently which has a smart builder for building separate parts in parallel, and using Takari plugins you can use the Eclipse complier which is parallelising in itself. See [http://takari.io](http://takari.io) for more details.

</comment></comment></comment><comment><USER48> I worked at Ning for a couple of years ([http://www.ning.com/](http://www.ning.com/)) and the internal codename of our create-your-own social network was Bazel.

When I first saw the headline I thought they'd open-sourced it.

</comment><comment><USER49> The "b"-with-leaves-sprouting-from-it logo is also used by [http://beanstalkapp.com/](http://beanstalkapp.com/)

</comment><comment><USER50> Will GYP/GN be deprecated in favor of Bazel?

What, if any, does the convergence among these projects look like longevity- wise?

</comment><comment><USER51> Will there ever be Windows support?

</comment><comment><USER52> This seems very promising. Does anyone know if this would this work with the OSGI framework?

</comment><comment><USER53> Fast - compared to what?

</comment><comment><USER54> Wohoo! This is awesome :)

</comment><comment><USER55> depends what you mean with reproducible: build a jar twice, and its md5sum will change because there are timestamps in the archive.

</comment><comment><USER56> What is this lameness? [https://github.com/google/bazel/tree/master/third_party](https://github.com/google/bazel/tree/master/third_party) \- why not use gradle repos to download jars with known hashes? Sticking all those jars in the git repo is just... well, I expected better from Google.

<comment><USER57> Try not to be so rude.

The FAQ is pretty clear about their reasons. It talks about tools, not other dependencies, but I'm sure the reasoning is the same: "Your project never works in isolation... To guarantee builds are reproducible even when we upgrade our workstations, we at Google check most of these tools into version control, including the toolchains and Bazel itself."

It's a sensible policy and one I use myself. Do you have a better reason for disliking this policy than a knee-jerk "yuck?"

<comment><USER56> Right, I'll try not to be so grouchy :-D

Some reasons are the bloat, the possibility of "accidental" forks when a non- upstream version is compiled and checked-in binary-only, crufty old versions hanging around, and security problems. It adds extra work for downstream packagers having to pick it apart for distros.

Bundling gets particularly bloaty for git repos, since the history is always included in each clone. For perforce or SVN it doesn't matter so much as you only get the latest version of everything. In git each time there's a dependency update, it will pretty much add the size of the new jar to the .git directory. Over time it's going to grow huge. If at a later date the repository owner decides on a new policy where the third party files are not bundled, then even removing the directory from the current head doesn't shrink the repo size.

There are binaries in there for Mac, Linux and Windows (.exe file at least). You either need one or the other, not all at the same time.

This sort of thing is fine for proprietary software used in a controlled environment, but for open source it looks kludgy.

An alternative could be to have a "dependencies" repository that would be shallow-cloned as needed. At least that way the source code repo only would have source in it, not jars or executables. It'd ensure separation was enforced and you could still track requirements per version or change the policy later.</comment></comment></comment>


Free Online Security Tools - <AUTHOR> https://market.secapps.com/ <comment><AUTHOR> Author here so let me know if you have any questions. We are refactoring our entire platform and I am hopeful we can get your feedback even if negative :)</comment>


Bing image of the day wallpaper with Python for Mac - <AUTHOR> https://gist.github.com/anonymous/5189417

<comment><AUTHOR> Just set it as a daily/hourly cron to make sure you have the latest image :)</comment>


Why the NRA hates smart guns - <AUTHOR> http://techcrunch.com/2016/04/30/why-the-nra-hates-smart-guns/ <comment><USER3> Good article, glad to see some knowledgable firearms writing in the general press.

This is how I've felt as a gun owner over the last two decades, translated into computing:

Imagine that someone in California hacked into a power station and caused a blackout. Police responded and found the hacker and their equipment. Shortly thereafter an "anti-hacking" bill appeared in the state legislature to prevent a repeat of such a disaster. The attacker used some strange system called Ubuntu which most computer users have little or no reason to have, so that was specifically outlawed in the state (while any other Linux distro is fine). They had a quad-core CPU, 16 gigs of RAM, and a USB 2.0 keyboard for "faster hacking"; the bill mandated a limit of 9 gigs, 2 cores, and PS/2 connectors only. The attacker also used something called the "TCP protocol" (misnomer intended); the bill also mandated that the protocol include a 4th and 5th step transmitting "I am not a hacker" and acknowledging "You will be prosecuted with a felony under California SB1137 for improper use of this TCP protocol".

The bill passes and no more hacks occur. Other states don't want to be seen as soft on crime, so they draft copycat bills and randomly ban openSUSE, Gentoo, and trackballs with more than 6 buttons. Within a few years computer enthusiast sites pop up detailing which states are safe to travel to with your laptop. 1 gig RAM chips get unexpectedly expensive as everyone wants to get up to that 9 gig limit in restricted states. California legislators visit university computer labs disapprovingly and talk about closing the "Linux loophole". Activist groups lobby Congress, maintaining that the Founding Fathers never could have conceived of computers as an evolution of the printing press and therefore the 1st Amendment did not apply to electronic devices or communications. Programmers everywhere grumble about coding for two different communication protocols depending on whether or not your users are in California (but it's such a big market you can't ignore it). Your mother wonders why you can't just get your work done on an 8 year old laptop running Windows 7, it's good enough for her web browsing!

The contractor maintaining the power plant control system again leaves the web admin panel open and unsecured after testing from home and forgetting to unflip a poorly labeled feature flag on the production server.

<comment><USER4> Computers have uses beyond hacking. Guns are for killing. Killing in self- defense, honing your killing skills as a sport/recreation activity, deterring bad behavior by threat of killing, killing things that are socially acceptable to kill (i.e. game animals), sure, but the theme is killing.

Lockpicks might be a better example. Many similar arguments apply: their use is to open doors without the correct keys, which only a few specialized professions should have a legitimate need to do. Yet on the other hand we ought to be able to tinker with our private property, evaluate its security (bad guys will get lockpicks anyway), let ourselves in if we get locked out, publish security research on "unpickable" locks and participate in locksport.

Or for a more direct computing analogy, Metasploit. It is unambiguously a hacking tool, but it remains legal because bad guys will always get hacking tools, and the good guys need to be able to evaluate their defenses.

<comment><USER5> Target shooting isn't just practice for killing things. That's as absurd as claiming "racing is just practice for running people over".

Target shooting is a sport all on its own, and is probably the single most prevalent application of firearms in the US.

<comment><USER6> when do you run things over when racing?

<comment><USER7> You don't. You also don't kill things when you target shoot. You can run over things with a car, or you can race one. You can kill things with a gun, or you can shoot paper targets with one. Get it?

<comment><USER8> The analogy is really stretched. The racing sport equivalent to target shooting would be running over paper targets.

<comment> nv-vn That's not an analogy, that's trying to directly apply the sport to another device. That would be like saying an analogy to soccer is kicking basketballs into hoops. The most natural thing to do with a car is to drive it and the most natural thing to do with a gun is to fire it. And running over paper targets instead of racing would probably be an improvement in motorsport safety ;)

<comment><USER6> the most natural thing to do with a car isn't to run people down though, it's to travel from one place to another.

target practice is to racing, as shooting people (or hunting) is to a road trip.

<comment><USER9> Appeals to nature are labored. What's the most natural thing to do with a knife then? A plastic bag? It breaks down pretty fast. In the end, a gun propels a lead slug at high speed and good accuracy over a distance of scores of yards.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER10> I'm an engineer, gun owner, and former NRA member[1].

I hate the idea of smart guns, but politics are a distant secondary concern.

Firearms fail all the time, even the simple reliable ones. Bad primers, failure to eject, failure to cycle, stovepipes, etc. It takes education and then repeated training to know how to deal with failures. In a pressure situation you revert to your lowest level of training; muscle memory will give you the best chance to respond appropriately.

Just dealing with mechanical failures quickly and correctly takes very intentional practice.

The last thing I want to have is another thing that can fail in a pressure situation that can't be resolved via trained response. E.g., for a bad primer or failure to eject I can do what's called a tap/rack/bang drill. But there's nothing I can do to train for some type of software failure or battery being dead or some other type of non-mechanical failure that bricks my firearm.

[1]Former because the NRA"s lobbing efforts and powers are ridiculously overstated. Their entire entire existence as near as I can tell is to sell their member's names to third parties. I've never received as much crap snail mail and email as I did during the year I belonged to the NRA.

<comment><USER11> They have a "do not promote" list that you must request to be added to which solves the spam/marketing mail problem. That you have to ask is problematic but there is a solution if this was the only problem.

<comment><USER10> It wasn't just that. Ultimately I decided that there were more effective 2A organizations that I preferred to support.

<comment><USER12> I'm saddened to hear your feelings on the NRA and its effectiveness.

While they, thankfully, haven't had to fight any big national gun control initiatives for some time, they are still very active at the state and city level. See their recent lawsuit against the City of Seattle and its new gun tax.

<comment><USER13> Well, if you want to fund lawsuits, the Washington state based Second Amendment Foundation is a better bet, and I'll bet they're a party to that lawsuit as well.

They are the only other effective one as I count them, but you have to donate money to them, a simple membership will just line the pockets of whomever is mailing out their stuff.

<comment><USER12> The value, as I see it, of the NRA is more its ability to efficiently mobilize 5 million members around key issues. I liken relying only on smaller, fractious orgs to when we had small state militias and no formal army.

</comment></comment></comment></comment></comment></comment><comment><USER14> This article is an ignorant POS.

The NRA hates smartguns for at least 3 reasons. First is the government is trying to force an unreliable and complex feature onto a product that needs to work every time. Second is the government has no plans to use it themselves, which speaks volumes about what their LEOs and the US military thinks of the reliability this technology. Last is the government is trying to solve a people problem with technology. BTW, these people problems are the result of Democrat's policies in gun-free cities such as Chicago, St Louis, Oakland and Baltimore.

<comment><USER15> "...trying to force an unreliable and complex feature onto a product that needs to work every time."

This. This is my biggest problem with smart-gun tech. We still haven't managed to figure out how to write software for hundred-million-dollar space projects that doesn't crash (the Japanese Hitomi satellite[2] being the latest of many); how on Earth are we going to implement smart gun technology correctly?

(actually, I would argue that we still can't write durable software _in general_ , and as such we should avoid integrating it into important things such as guns and cars until we can improve our development skills)

[1]: [https://www.newscientist.com/article/2086422-japanese- satell...](https://www.newscientist.com/article/2086422-japanese-satellites- death-spiral-linked-to-software-malfunction/)

<comment><USER16> The plan is not to ban non-smart guns next week. Obama is calling for a push to improve the technology until it becomes reliable. Despite the Hitomi failure, we have sent a few hundred things into space pretty successfully. Half the systems in your car are under computer control. Opposing technology that could save thousands of lives a year because it doesn't work perfectly yet is bullshit.

<comment><USER17> I think what most opposition to smart guns centers on is the assertion that the technology could "save thousands of lives". It would be great to see hard numbers of exactly how many people are killed with immediately stolen guns, and I doubt it would be in the thousands.

As the author's prior article in the series notes, such technology will almost invariably be easily bypassed. Criminals will, unfortunately, remain criminals, and will disable the technology or continue to buy guns underground. None of this even addresses the fact that many murders are perpetrated by legal owners of said guns, which this technology would do _nothing_ about.

As is usual with such things, if smart-gun technology were legislated its only measurable effect would be on law-abiding citizens, adding yet more potential felonies to the maze we traverse daily.

</comment></comment></comment></comment><comment><USER18> The article makes it sound theoretical, but New Jersey already has the Childproof Handgun Law that makes it illegal to sell a non-smart gun "three years after it is determined that personalized handguns are available for retail purposes." [https://en.wikipedia.org/wiki/New_Jersey_Childproof_Handgun_...](https://en.wikipedia.org/wiki/New_Jersey_Childproof_Handgun_Law)

<comment><USER13> And that's been seriously proposed in California, which is pushing through another wave of gun control legislation, one bill of which would effectively shut down all gun stores in the state, and certainly favorably talked about elsewhere ... maybe Maryland?

Just skimmed it (too much going on right now to look at it in depth), but I'm seriously impressed they did so much work to get in things like the classic "shoulder thing that goes up". In their defense, New Jersey's law is, as I recall, much older.

I'll mention one other bottom line: we wouldn't even consider it prior to all law enforcement officers in the nation being required to use them, and only them.

<comment><USER19> Part of the push for smart guns for law enforcement would come from law enforcement's negligent inability to keep track of their own weapons. A local news channel covered the story of one Bay Area city's police department releasing a report on an inventory of the weapons used by police officers. They were literally missing hundreds of them. Often, the weapon would be lost when an officer left it in an unlocked car, either a police car or their own and the thief simply opened the door/trunk and took it.

<comment><USER13> I suppose so, but it's not like that would make any difference in the number of illicit guns on the street, and I've never heard of smart guns being designed for that much harder use case, where an adversary had lots of time to modify them. The most common one is limiting who can fire it, e.g. preventing the all too common tragedy when a criminal snatches a cop's gun and kills him with it.

<comment><USER20> > all too common tragedy

Any murder is too much murder, but I certainly wouldn't describe it as common. Cops are nearly as likely to die of a car accident as they are of getting shot. A cop friend of mine was going on about how the recent media focus on them has made things so dangerous - officer murders were up by 15%! I asked him if that translated to an increase of 5 or 6 a year, and if that was actually above the noise floor - he responded with a blank stare - "15%."

<comment><USER13> Well, you're got a point, especially with modern retention holsters, but it's still a major issue, and those holsters also slow down the draw speed of officers (but one defeated the Boston bombers' after they murdered the MIT Campus Policeman, that murder was for naught).

<comment><USER20> I stopped having to carry daily around the time that serpa holsters got popular. All the combat vets accurately predicted that the release mechanism would lead to a lot of negligent discharges - many training courses wouldn't let you on the range with one. I'm surprised to see that they are still being sold, I'd have thought they went the way of the lawn dart.

<comment><USER13> The Serpa holster is by no means the only retention holster out there! Nor would have one stopped the Boston bombers from what I understand of them, it's hard to expresses just how bad an idea they are in every way.

For those who don't know, you have to press a button about over where the trigger is, inside the holster. If you keep pressing into your draw, you may as many have found out continue and press the trigger while it's pointed in a unfortunate direction.

<comment><USER20> I'm going to have to disagree with you, I think thumb break retention holsters (that have been the standard forever) are just fine. The usability problem for holsters comes from the loss of fine motor control following an adrenaline dump, you go all thumbs. Of course nothing beats boring old training - <USER2> even very complex behavior can be ingrained. I blacked out my first fire fight, but I was later told that I effectively performed three magazine changes, manipulated the radio, called in a SALUTE and fired a signal flare. I'm confident that if I spent several years training to not shoot myself in the leg with a serpa holster, I could, but it would be a waste of time as better holsters long predate that silly design.

<comment><USER13> I'm actually not sure we're disagreeing, but I'll defer to you, seeing as how I've avoided firefights up to now, and probably will in the future, and carry concealed with a Summer Special, friction the only retention besides, of course, having it covered.

Ah, also a Safepacker in winter weather, which is not even clearly a hostler: [http://www.thewilderness.com/safepacker-concealment- holster/](http://www.thewilderness.com/safepacker-concealment-holster/)

<comment><USER20> Oh yeah, we are talking about different use cases. I'd never advocate anything that would make an IWB draw any slower than it already is :) For the more block inclined, MIC trigger guards are nice for winter jackets.

<comment><USER13> I worship at the alter of John Moses Browning, so no MIC holsters for me any time soon.... But I have many many others to choose from, they've been insanely, amazingly even for me popular with civilians for a long time.

And, yeah, slow is a good word to use there ^_^.

(#1 one overriding reason is that since I was a teen the M1911 fits my hand like a glove, and I can shoot it very well. And 8 round magazines weren't a big forfeit when I started buying handguns after leaving Massachusetts and the Federal AW ban was in effect.)

<comment><USER20> For a long time I felt the exact same way (also big mitted), but I got challenged to leave the Springfield at home and use a borrowed G17 for a week long course. I still prefer the M1911 for sport, and satisfying my need to constantly tinker (yes my feedramp is polished and ejection port flared). But if I were pressed - I'd begrudgingly go with the utilitarian choice offered by Glock. But everybody has their reasons for developing preferences in their tools: I will give up my modal text editor when they peel my cold dead fingers from around it.

<comment><USER13> And I'll give up my non-modal EMACS when....

Although the grip angle of Glocks is just plain wrong for me, I've read that I ought to try the Springfield XD if I wanted to go in that direction. Which I don't, for concealed carry I believe an external hammer is essential for holstering safety (put your thumb on it and either stop the drop if SA or feel it rising if SA/DA or DAO).

And, yeah, given that I can shoot most guns well/very well (a couple of years of JROTC rifle team with Winchester 52s, after informal starting in 1st grade or so, made a big difference, but don't ask me to wingshoot), yeah, I should give something different a serious try just to see. I'll put it on my list.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER21> Smart guns aren't going to hinder anyone but responsible people.

We need a few things:

1) Funding alternatives to incarceration. People that go to jail tend to have a frequent flyer card.

2) Law enforcement sharing of critical data on offenders.

3) Funding treatment and therapy programs for drug abusers (ABUSERS, key word. I know this isn't a popular opinion on HN, but ABUSE and USE are two different things)

4) Finally, we need to wake up and realize there ARE bad people in the world, and unless you live in a small community, you can't have 100% safety. You can react by protecting yourself (yes, carry concealed), or if you're not comfortable with that, take a professional classes on how to survive extreme situations. Your safety at the end of the day is your responsibility ultimately.

<comment><USER22> I've always thought that the arguments from the anti-gun crowd defied all logic. If access to guns was the root of the problem, then gun violence should be going down, rather than up. Far fewer people own guns now than did, say 150 or 200 years ago (when it was probably close to 100%). Solving the problem by focusing on guns is trying to treat the symptom rather than the disease.

<comment><USER13> I don't think you're right about how pervasive gun ownership was, due to changes in costs and wealth, and the ability to maintain guns in the days of corrosive black gunpowder and corrosive percussion caps and primers (the WWII M1 Carbine was the first US weapon system to use non-corrosive primers). And of course blacks were largely disarmed post-Reconstruction, next up were post- Civil War immigrants starting around the last turn of the century, etc. See also Chicago post- _McDonald_ and the nationwide sweep of shall issue laws has radically increased the utility of owning a handgun, now 43 states and ~72-3% of the population.

</comment></comment></comment><comment><USER23> Smart guns have an interesting history. In the 90's Colt developed a smart gun, but the results "backfired." Anti-gun groups were against it because of the idea that safer guns meant that the barrier to entry to ownership was lower (now that guns are "safer", why not have one?); people who depended upon guns for their livelihood were skeptical: when you need to use one there needs to be no questions that it will function (barring all the traditional issues of "dumb" gun); if successful, other manufacturings would have to follow suit and there could be legal actions against "dumb" gun manufacturing and ownershpi...etc.

I've linked some articles that touch upon this attempt by Colt.

NRP Article: [http://www.npr.org/2016/04/07/473416699/how-an-idea-to- devel...](http://www.npr.org/2016/04/07/473416699/how-an-idea-to-develop-a- safer-smart-gun-backfired)

Hacker News Discussion of Article: [https://news.ycombinator.com/item?id=11462297](https://news.ycombinator.com/item?id=11462297)

<comment><USER13> From the beginning of the first comment in the HN discussion you link to:

 _he explained that it was only supposed to fire if the shooter was wearing a special wristband with a little radio frequency transmitter inside. The CEO put on the wristband and went to pull the trigger. ... And it didn 't shoot. Just silence._

An "oops" which is entirely unacceptable for any law enforcement/self defense use case.

</comment></comment><comment><USER24> Smart guns are to self-defense and the gun industry what the Clipper chip was to encryption and the communications industry, except the Clipper chip actually worked.

<comment><USER25> Except that literally no one would die if clipper worked or didn't work. I lean toward the side of fewer restrictions on guns, although I don't own any - but I don't think that any comparison that removes the possibility of people dying will really hold up.

<comment><USER24> The reason that the government wanted the Clipper chip was to make it possible for police agencies to listen in on the encrypted communications of suspected criminals, often ones whose activities would certainly involve the possibility of people dying.

Both cases are examples of government attempting to interfere with a technology to further some legitimate public government interest (catching criminals, reducing accidents) while compromising the private interests of citizens (effective self-defense, privacy).

</comment></comment></comment><comment><USER26> Everybody[1] who's actually owned a gun (or plans to) hates smart guns.

[1]: Okay maybe not _everybody_ but based on my anecdata it's everybody.

<comment><USER27> That's the conclusion I came to when looking at the market for smart guns (I was interested in smart attachments for guns, think Fitbit for your gun). Smart guns drum up a bunch of press and buzz from people who will never buy them. It's a failure to understand the target market, who hates the concept for reasons mentioned elsewhere in this comment section.

</comment></comment><comment><USER28> Washington regulates a million things over which is has no particular expertise. Including, but not limited, to medicine, dentistry, pharmacy, food production, law, agriculture, investment banks, the oil and gas industry, and on and on.

The fact that the government is bad at regulating these things doesn't mean that any step they take will be bad. The details matter, and it doesn't mean you should terminate any regulatory effort before it is defined.

In many (maybe all) of these areas, some regulation _is needed_.

<comment><USER12> Most of those areas are regulated by boards and committees of dentists, pharmacists, food specialists, etc.

For whatever reason, gun control is the one area where politicians refuse to consult specialists, thus resulting in bills as ridiculous as the AWB.

</comment></comment><comment><USER29> If the better approach is to focus on the "who", why does the NRA oppose background checks?

<comment><USER30> I think we all know why. In fact. This author implies it: the NRA actually represents the business interests of people who manufacture and sell firearms. They may mask these interests as a public service, defending your rights and hobbies and whatnot but it is always the case that they oppose anything that would reduce firearm sales and support anything that makes it easier for you to get a gun.

<comment><USER3> I disagree. The NRA has 4 million American members which I think makes it the largest lobby by membership. I doubt they're all pawns of the gun industry.

If the NRA wanted to solely juice sales and sell more guns they would give heavily to elect more Democratic candidates. The current presidency has been great for sales [0].

0 - [https://www.fbi.gov/about- us/cjis/nics/reports/nics_firearm_...](https://www.fbi.gov/about- us/cjis/nics/reports/nics_firearm_checks_-_month_year.pdf)

<comment><USER31> Left-wingers ranting about the "gun lobby" are like right-wingers ranting about the "LGBT lobby". Everybody loves to pretend that the opposing political party is driven by some strange, inhuman machine, not by a bunch of normal people pretty much just like themselves.

<comment><USER32> LGBT lobby? And what this lobby political agenda would be? Promoting skinny jeans?

(I consider myself to be a right-winger, as I am certainly pro-gun and pro- business, and straight as a rail, but I never heard about LGBT lobby concept, except in jokes about fashion. LGBT guys and gals are fun.)

<comment><USER13> Try [https://www.google.com/#q=target+transgender](https://www.google.com/#q=target+transgender) for example.

</comment></comment></comment></comment></comment></comment><comment><USER32> I wouldn't say "hate", as it is too strong a word. But smart guns have the same problem as self-driving cars: they take control from you and transfer it to unknown actors (a random computer programmer? Clueless legislators? Various three-letter government agencies?)

Conversely, anti-gun folks and self-driving car proponents consider guns and cars too dangerous to be left in hands of _those people_. Those a better left in hands of experts, they say.

<comment><USER33> > Conversely, anti-gun folks and self-driving car proponents consider guns and > cars too dangerous to be left in hands of _those people_. Those a better > left in hands of experts, they say.

That sums up my position nicely. I would not trust myself with either of these things.

<comment><USER34> Well, that's your self-confidence problem. It's not my problem, so don't try to impose it upon me.

</comment></comment></comment><comment><USER35> I'd be a lot more interested in a smart gun SAFE than in smart guns.

What I want most, specifically, is a bedside pistol safe, the size of a "gun vault", which is actually secure, but still rapid-access.

(The problems with the "gun vault" style safes are numerous -- some of them can be simply dropped 6" and they pop open from inertia on the locking mechanism. Others can be defeated surreptitiously by peeling off a sticker and inserting a paperclip to hit the reset button inside. They're not suitable for leaving a loaded firearm inside when you have untrustworthy people about for extended periods. The only reasonable model right now is to take a carry gun and put it in the safe every night (which is great IFF you carry every day), or to transfer a weapon from a "real" safe to the bedside vault every night. The problem is at some point you might forget, and both false-positive and false-negative kind of suck there.)

The tradeoff I'm willing to make is spending $1k for this vs. $100, and accepting two distinct entry modes: an slow-path "unattended/unprimed" mode which uses a UL group II electronic lock for access, with timeout-access, and a fast-path "day gate" (which would actually be night gate...) which opens quickly using (ideally) a chording keyboard mechanism, or biometric, or something else.

What I absolutely want to defend against is surreptitious entry when unattended -- i.e. for someone with kids, capable of entering hundreds or thousands of combinations in a week, there should be very low risk of users brute forcing the combo or otherwise gaining access in a way which doesn't leave evidence/alarm. Ideally, tamper events would lock the safe down to full TL-15 mode; if your kids can defeat a TL-15 safe, particularly surreptitiously when it is monitored every day, they might deserve the firearm for their new life of crime.

I'd be willing to have no override capability on the fast-path -- if it misreads, or is at all suspicious, if fails back to the slow-path. The mechanism for enabling fast-path might be unrelated to the slow-path entry mechanism (i.e. you don't need to open the door); what I was thinking of was some kind of presence-detect using bluetooth watch (Apple Watch) challenge- response, or something like that.

I could accomplish this today by buying an actual UL TL-15 safe of some size and putting a gunvault inside it, but that takes up a lot of space, and would weigh half a ton. There has to be a better solution.

I'd also like to have it tied into my alarm system and notifications -- if someone attempts to enter the safe, I want a notification on my phone. I'd also like to be able to force slow-path-only remotely. (I'd _also_ like to have lighting, cameras, etc. controlled by alarm events, but that's a separate thing; I'd prefer NOT to have my bedroom recorded on video normally, but when the gun safe is opened, I'd like video logs to be streamed offsite in realtime.)

</comment><comment><USER36> These threads are always so weird to me - from a country where I have never known someone who owns a gun or ever seen one outside of police carrying them.

<comment><USER37> Growing up, I can't think of anyone I knew that didn't have guns, or who professed to believe they should be restricted further.

</comment></comment><comment><USER38> Interesting to me how many people feel so strongly about a topic, often to such a degree that they openly void having an understanding of views counter to their own and unable to express the reasoning behind their own beliefs in any meaningful way.

To me, this is the real issue, not that there's a topic people disagree on.

_______

Re: SmartGuns — People kill people, and if someone wants to harm someone, they will. To me, a more natural solution would be to have areas, much like schools, that're gun free, and others that are not. Clearly this won't fit the issues, but it might end the debates.

</comment><comment><USER39> ...somewhere a tiny yellow light blinks at 20 bpm in a the NRA chapter tasked with online argument response, and three pagers subsequently buzz...

</comment><comment><USER40> DC v. Heller means nothing will come from any of this.

<comment><USER13> Not clear. Prior to Scalia's death, on the ground if you don't count Illinois, which was not appealed to the Supremes, and California and Hawaii, where it looks like the appeals court will overturn the current shall issue decision _en banc_ , on the ground there's been no changes, because the Supremes have denied cert to _every_ case appealed to them aside from the Massachusetts stun gun case just decided.

The bottom line is that _Heller_ and _McDonald_ mean we have a right to keep some types of arms, and bear them inside our homes, nothing more. And surely you've noticed how replacing Scalia is claimed by gun-grabbers as a necessary step towards reversing, _de facto_ or _de jure_ , both of those decisions, e.g. [http://thehill.com/regulation/277248-chelsea-clinton- scotus-...](http://thehill.com/regulation/277248-chelsea-clinton-scotus-open- to-gun-control-after-scalia)

</comment></comment><comment><USER41> I don't want backdoors in my guns just like I don't want backdoors in my encryption. It's really that simple.

Also reminder that Marx was an advocate of widespread gun ownership by the working class, much for the same reasons that the founding fathers of the USA were. Solving the underlying economic issues causing suicide and violence would make far more sense than covering up the symptoms. At the end of the day it's all about poverty.

<comment><USER42> I think that Marx comparison is pretty wrong. Marx expected a global workers' revolution that would result in a classless society. He was an advocate of armed revolution against the bourgeoisie. As far as I can tell, anything he wrote about gun ownership was in the context of this armed revolution.

The second amendment reads, in full, _" A well regulated militia being necessary to the security of a free state, the right of the people to keep and bear arms shall not be infringed."_ The notion of protecting a state lead by a capitalist, slave owning class (think about what "people" means in this context) is completely contradictory to Marx.

<comment><USER43> Marxists have enslaved far more people that were ever enslaved by the "capitalist, slave-owning class" in the early United States.

</comment></comment></comment><comment><USER44> Reasons against smart guns - smart appliances don't work well, never have, never will. I prefer things simple, mechanical and working instead of praying that some Dilbert style company developed an usable software.

I live in a country that has very restrictive gun ownership regime - and yet every person knows instinctively about the gun safety rules:

1\. Always assume loaded, unless proven otherwise 2\. Don't point it at something you don't want to kill.

I am sure that people will appreciate when their gun starts firmware update or resets during a boar charging at you situation.

</comment><comment><USER45> The vertical forward handgrip claim is a bit much. While not too useful for aimed fire, as the author points out, it makes un-aimed "spray and pray" shooting easier. So does a barrel shroud. Neither feature is needed on a hunting rifle.

<comment><USER46> You don't know what you're talking about and I'm guessing you may have never actually shot a semi automatic rifle before.

This is a rifle with no scary barrel shroud, pistol grip, or vertical foregrip. If you google "bump fire" you might notice it is pretty easy to rapid fire just about anything as long as it's semi automatic and you don't much care if you hit anything.

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

In fact I find pistol grips and vertical foregrips plenty ergonomic for aimed fire, especially because I have a bit of carpal tunnel going on and cocking my wrist is somewhat painful. That's why every olympic target rifle (eg the Anschutz) uses some version of a vertical grip.

<comment><USER45> The US Army once taught me to use an M-16.

<comment><USER17> Being trained in a device's use does not an expert on its design make.

</comment></comment></comment></comment><comment><USER47> The irony being is that the gun community acts just as irrational and certainly impractical. Even as a non-gun owner, I know what gun I'd rather have for self defence than these guys. :)

Does a 50cal really seem like a sport rifle? The inventor goes on towards the end of this video to suggest it's useful for personal self-defence?

[https://www.youtube.com/watch?v=1n3usocws0E&t=0m42s](https://www.youtube.com/watch?v=1n3usocws0E&t=0m42s)

Here's an example of a guy who has 1.5M subscribers explaining how he'd protect himself answering the door in the middle of the night with a completely impractical close range weapon.

[https://www.youtube.com/watch?v=bLiWhFTfUCg&t=3m33s](https://www.youtube.com/watch?v=bLiWhFTfUCg&t=3m33s)

<comment><USER48> Those youtubers are just jerking off. A .50 caliber rifle is just a big expensive dangerous toy. No one is going to commit a shooting spree with one. It's not practical. Regulating them only impacts people who like loud bangs and will never hurt anyone.

<comment><USER49> My congresscritter a while back put out a statement supporting the 50 BMG ban in California, because she wanted "these dangerous weapons off our streets." I emailed her, asking how many of these weapons, exactly, she'd happened to find on our streets! I figure, they're so rare and expensive, if I could walk outside and trip over one, I might as well go out and pick one up that'd been left in the nearby hedges! She didn't respond. :-(

Tangent: It made me wonder what the longest distance criminal shot in American history is. Anybody got any ideas?

<comment><USER35> Do you mean "criminal shot by police/civilians", or shooting-by-criminals?

Pure negligent shootings which happen to damage property or injure/kill people happen at range all the time, and the shooter is by definition a criminal. Celebratory fire, particularly at a 30-45 degree angle, is going to have serious range, even if inaccurate, and is guaranteed to hit _something_.

Most of the fear of .50 was anti-armor, not so much pure range.

The "DC Beltway sniper" fucktards ([https://en.wikipedia.org/wiki/Beltway_sniper_attacks](https://en.wikipedia.org/wiki/Beltway_sniper_attacks)) were under 200m shots, but that's still solidly rifle distance.

Famously, Charles Whitman ([https://en.wikipedia.org/wiki/Charles_Whitman](https://en.wikipedia.org/wiki/Charles_Whitman)) had many shots resulting in injury or murder at 400-500m. He was firing from a tower, and high angle shooting rewards flat trajectory even more than the distance itself would indicate.

JFK was 81m, also well outside handgun range. I suspect there are a reasonably large number of 50-200m range shootings with rifles (there are very few shootings with rifles overall, but when they do happen); that's easily house- to-driveway-end in a lot of places.</comment></comment></comment></comment>


SABLE – An open source bootloader to establish mutual trust - cti-j https://sable.critical.com/ <comment> cti-j github - [https://github.com/CriticalTechnologiesInc/SABLE](https://github.com/CriticalTechnologiesInc/SABLE)

website - [https://sable.critical.com/](https://sable.critical.com/)

Some papers produced as a result of this effort:

* Formal Verification of a Modern boot Loader [https://surface.syr.edu/eecs_techreports/183/](https://surface.syr.edu/eecs_techreports/183/)

* A Formally Verified Heap Allocator [https://surface.syr.edu/eecs_techreports/182/](https://surface.syr.edu/eecs_techreports/182/)

* A High-Level Overview of SABLE [https://sable.critical.com/media/whitepaper-sable.pdf](https://sable.critical.com/media/whitepaper-sable.pdf)

It's certainly a work in progress, and lots planned for the future, but we wanted to share this with the community sooner than later. Happy to answer any questions about it that I can!</comment>


Recreating the spectrogram face - <AUTHOR> http://danielrapp.github.io/spectroface/

<comment><USER2> _Venetian Snares '_ also had something similar in his _" Songs About My Cats"_ album: [https://www.youtube.com/watch?v=Qlpakpa8zIA](https://www.youtube.com/watch?v=Qlpakpa8zIA)

<comment><USER3> I made something like that, too, but it's not currently online and just a short derpy chip-ish tune anyway.. though the image I embedded was little heart shapes, and they went nicely with the music, so there's that haha.

I used this for it: [http://victorx.eu/BitmapPlayer.htm](http://victorx.eu/BitmapPlayer.htm) To imagine we can that with moving images in the browser now, well, whoa.

</comment></comment><comment><USER4> ARSS [1] is a similar tool, check the examples [2]. LTFAT toolbox could do something similar using isgram function [3].

[1] [http://arss.sourceforge.net](http://arss.sourceforge.net)

[2] [http://arss.sourceforge.net/examples.shtml](http://arss.sourceforge.net/examples.shtml)

[3] [http://ltfat.sourceforge.net/doc/demos/demo_isgram.php](http://ltfat.sourceforge.net/doc/demos/demo_isgram.php)

</comment><comment><USER5> The Analysis & Resynthesis Sound Spectrograph[1] is a really nifty tool that can convert spectrograms to audio files and vice versa, making tasks like this trivial. Sadly the developer has shifted development into a proprietary project, but the last release of ARSS still works and is a real hoot to play with.

[1][http://arss.sourceforge.net/](http://arss.sourceforge.net/)

</comment><comment><USER6> MetaSynth is all about that, you can import visuals, draw over them, filter them and then go back to audio, MetaSynth is available since a very long time, it was first running on Mac OS 9. [http://www.uisoftware.com/MetaSynth/index.php](http://www.uisoftware.com/MetaSynth/index.php)

<comment><USER7> This is what RDJ used to make the sounds in the b-side on Windowlicker.

</comment></comment><comment><USER8> Forgive my ignorance but does a spectrogram carry all the information necessary to reproduce the sound that generated it? For example, assuming I had the spectrogram of a song, could I play the song using it?

<comment><USER9> The Discrete-Time Fourier Series is invertible. The problem is that for each pixel the Fourier series is a complex number and what is plotted is the magnitude (so the phase is not shown). Reconstructing a signal from only the magnitudes of the Fourier coefficients is ill-posed, i.e. there are multiple signals with the same Fourier coefficient magnitudes.

Still there is active research on reconstructing signals from only the Fourier magnitudes (under several assumptions). This is called the 'phase-retrieval problem'. [http://en.wikipedia.org/wiki/Phase_retrieval](http://en.wikipedia.org/wiki/Phase_retrieval)

</comment></comment><comment><USER10> This is really innovative!

</comment><comment><USER11> This made me listen to some Aphex Twin. Ouch. Luckily I soothed my ears with some Black Dog: [https://www.youtube.com/watch?v=GUl6iJlEeTE](https://www.youtube.com/watch?v=GUl6iJlEeTE)

<comment><USER12> Aphex Twin has made some softer songs as well, a popular one being this: [https://youtube.com/watch?v=iiZEto2j2GQ](https://youtube.com/watch?v=iiZEto2j2GQ)

His newest album Syro also has less aggressive tracks, but it seems to not be on YouTube.

<comment><USER13> Or if you want a super soft one, how about this: [https://www.youtube.com/watch?v=nWnUuosQwZY](https://www.youtube.com/watch?v=nWnUuosQwZY)</comment></comment></comment>


The Future Will Be Personalized - <AUTHOR> http://techcrunch.com/2010/11/16/the-future-will-be-personalized/ <comment><USER2> Actually I just gave a short nerdnite talk pointing out the shift from "branding" to "individual judgments," noting its pending arrival in education & politics, and originally calling it "the age of individuality."

<http://www.youtube.com/watch?v=tZY_hZLY-HE#t=3m43s>

I also think this will be the defining "next age of the internet," to the extent such things exist.

</comment><comment><USER3> I haven't added many new facebook friends in the last year but I can no longer keep up with my news feed anymore. It certainly seems the signal to noise ratio is going up and the social filters are becoming overwhelmed.

</comment><comment><USER4> legit stuff</comment>


Ask: Why not implement a "url database" with all the news? - <AUTHOR>

I started checking periodically the news site since last week and noticed the avalanche of news; sadly, most of them are "repeated" news that sometimes displace the "old" ones and thus, making the current thread "useless".
Wouldn't it be better to have some URL database and whenever someone is "double posting" the same link just append that to the "old" thread?
Just an idea to keep this place a little bit more organized.
What do you think? <comment><USER2> Or we could just use Reddit's codebase, which already handles a lot of these things very gracefully.

Kind of like how <http://www.thecutelist.com/> just points to a modified <http://www.reddit.com/r/aww>

<http://news.ycombinator.com/> could point to <http://www.reddit.com/r/hacker_news>

</comment><comment><AUTHOR> @benologist yeah, what worries me the most is that right now this site is becoming something like that. Looks like people would rather post the link than look around here and see if the topic was already "posted"

@nathan_f77 that's a great idea, I mean, that would make the site so much cleaner and will keep more "real" content being pushed.

</comment><comment><USER3> HN could just crack down on all the blogs rewording someone else's article, that'd cut down on duplicate stories.

Rewrites via x via y via z aka most of AOL's properties and the many blogs that copy their business model should get killed. It might even encourage some of them to write some original content for a change.

</comment><comment><USER4> Are you talking about this site? Submitting the same link twice will not create a new submission, it'll redirect the submitter to the existing one. If there's a duplicate, there's some difference in the URL.

<comment><AUTHOR> yeah, i'm talking about this site. The think is that you can browse through the first 4 or 5 pages and you will notice a bunch of duplicates; which is sad because among a lot of duplicates and posts about exciting things in twitter the real content gets lost.</comment></comment>