Announcing .NET Native Preview - <AUTHOR> http://blogs.msdn.com/b/dotnet/archive/2014/04/02/announcing-net-native-preview.aspx <comment><USER2> It seems the comments area here is full of lots of questions and few answers. Let me try to clear some things up.

 _Lets start with how it currently works..._

When you create an application or website in C#,F#,VB.NET or any other .NET language you are not really 'compiling' it per se to native code, you are compiling it to an intermediate language called IL - very much like Java byte code. When your application or website is run for the first time the .NET runtime converts this code to native code on the local computer and then caches this binary and officially compiled native version of your code. The result is, the first time you run your app or a section of the code there is a small performance hit while the .NET runtime converts your code to native. Let me be perfectly clear, this is a one time thing - a first time thing. Once you have gotten past that every subsequent run is going to be as fast as other native code. (Why is it not as fast as something written in c or c++ you may ask - because there are other things the .net runtime is providing for you like garbage collection, but that is a whole other talk)

 _So how is this different?_

This preview allows you to skip this JIT process and image caching process altogether. This is first targeted for Windows store apps, when you would first run it on your machine it was slow on first launch because all this extra work was being done. Microsoft decided they could take the server side resources they had and run this JIT and imaging process ahead of time and when someone downloads and installs your app - this work was already done and first launch would be faster - as much as 60% faster. There are also lots of changes under the hood to make this all work better - Andrew Pardoe is on this comment thread further down and mentioned things like a refactored runtime, static- optimized libraries, static marshalling all combining for performance wins.

 _Does this mean I can build apps for Unix with C#_

No, Mono is still the best way to do that

 _Can I build simple console apps with this and deploy to machines without the .NET runtime?_

No, right now this is only available for Windows Store apps. Besides, unless you have some Windows 98 machines sitting around nearly every PC has the .NET runtime.

 _Will this make my app run faster?_

Starting up, yes. Normal operation, probably not. .NET runtime and jitter have been around a long time and they are impressively efficient and fast. This includes some tweaks to parts of the runtime but don't expect to see your text file processing app go from 10 seconds to 2 or something like that.

 _Will this help me pick up chicks?_

Depends.

<comment><USER3> How good/reliable is Mono on Linux now? If I knew _for sure_ that people are actually using Mono on Linux robustly and with good performance I would ditch the JVM - as a language/runtime .Net is so much better...

<comment><USER2> How good is Mono - Unity3D is based on it and I have not heard anyone complain that the thousands of games built with it (including some of the most popular ever on iOS and Android) are having performance issues because of the underlying architecture.

<comment><USER4> Relative to the JVM, Mono on Linux is slow as heck.

</comment></comment></comment></comment><comment><USER5> So, uh, can I compile my C# app to an bare x64 .exe file, statically linked with no runtime dependency on the .NET Framework, that will run on Windows 7 and 8? Or not?

Edit: This is a much better link: [http://msdn.microsoft.com/en- US/vstudio/dn642499.aspx](http://msdn.microsoft.com/en- US/vstudio/dn642499.aspx) Still not sure though, as they say "only Windows Store apps can be created" which sounds suspiciously like "no".

<comment><USER6> From the original link they say "Today's preview supports Windows Store applications. We will continue to evolve and improve native compilation for the range of .NET applications." which suggests to me that it might be on the radar. However the scope of Windows desktop or server applications is obviously much broader, so it might be a harder problem to solve there.

<comment> apardoe-MSFT @jimmcslim Quite right, the smaller Windows Store profile is a more scoped target. But everything is on the radar.

</comment></comment></comment><comment><USER7> I'm kind of scratching my head here, can someone explain what problem this solves? There's already a CLR and already a way to build native apps for Win 8, etc. This is a new CLR that can run new 'native' apps?

<comment><USER8> It gives faster startup time (due to AOT compilation rather than JIT), and doesn't require that the .NET framework be installed. Possibly better runtime performance, but I wouldn't expect huge gains there. P/Invoke should have lower overhead, which may be highly relevant for some things.

I suspect that there's things that require this which they haven't announced yet, since on its own it seems like something kinda nice but not beneficial enough to justify creating.

<comment><USER7> Yeah I don't understand the need to get rid of a .NET framework dependency though. This only supports building Windows store apps, which only run on devices that have the .NET framework right now...

<comment><USER9> One admittedly crazy theory is that this is laying the groundwork for building iOS apps and therefore would compete with Xamarin. Any kind of JIT would not be allowed on the iOS app store.

<comment><USER10> The word is, that Microsoft is talking with Xamarin about a possible acquisition.

</comment></comment></comment></comment></comment><comment><USER11> What is the difference between this and NGEN? Anybody?

<comment><USER12> No MDIL. NGEN can still JIT for things like cross domain generics and because it loads non-native code, still needs to optimize at run time.

Project N compiles to fully native code, so there can be no JIT, and significantly smarter optimizations can happen since they don't impact performance at runtime.

<comment> apardoe-MSFT @Pantaloons: Right on all counts. One clarification: .NET Native and MDIL are orthogonal. MDIL was used in Triton to split NGen into conceptually two pieces: the optimized part (in the Windows Phone Store) and the part bound on the customer's device to the installed Framework.

.NET Native produces completely native binaries. MDIL/Triton produces NGen binaries that still need a runtime and, occasionally, a JIT.

<comment><USER13> And Triton is...

<comment> apardoe-MSFT Pay attention, Scott :)

Sorry. Triton is the Windows Phone 8 "Compiler in the Cloud". It basically split NGen into two pieces, allowing the optimization to happen in the Store while the .exe generation happened on the device. The interface between these two halves is MDIL.

Bing will tell you a ton about Triton.

<comment><USER13> Sorry, I see this in just one place. Sounds like an internal code name. [https://www.google.com/search?q=Triton+.net+compiler](https://www.google.com/search?q=Triton+.net+compiler)

</comment></comment></comment></comment></comment></comment><comment><USER10> Was someone from marketing writing this: "the performance of C++ with the productivity of C#" ... on startup. And not even on every startup, but only the first. And not even the first, since, as you know, there already are a lot of (unarguably, productive) features (such as GC etc.) making apps slower than C++ apps.

Also, is it just me, but this sounds like a glorified NGen in the usual build process (compiling for production goes straight to native), instead of NGen in the background optimisation service?

I am all about getting the new tools, switching to new, more productive ways of development (in fact I was programming in C# for about 3 years), I simply hate when false information is being spread, just because it sounds better to the sales person.

</comment><comment><USER14> Do native apps still require a preinstalled CLR?

<comment><USER8> No. Second entry in the FAQ ([http://msdn.microsoft.com/en- US/vstudio/dn642499.aspx](http://msdn.microsoft.com/en- US/vstudio/dn642499.aspx)).

<comment><USER14> Damn, that's awesome! For the longest time that was the only thing that really bothered me about writing .NET code.

<comment><USER15> But doesn't anyone with the Windows Store already have the CLR?

<comment><USER14> Probably -- I don't care too much about the windows store, I'm more excited about being able to write C# code that doesn't require a VM. Not that there's anything /wrong/ with the CLR, but one thing I miss about C++ when I'm not writing it is self contained programs where it's just a small exe without a bunch of huge dependencies.

<comment><USER16> I think you're forgetting about the Visual C++ 20xx Redistributables. They aren't exactly tiny. [https://www.dropbox.com/s/eizfqwg0ouiq4ql/Capture3.PNG](https://www.dropbox.com/s/eizfqwg0ouiq4ql/Capture3.PNG)

vs. the latest .NET install

[https://www.dropbox.com/s/eizfqwg0ouiq4ql/Capture4.PNG](https://www.dropbox.com/s/eizfqwg0ouiq4ql/Capture4.PNG)

This is a brand new Windows 8.1 computer.

<comment><USER5> The redistributable is huge but not required. You can statically link the C runtime. That option has never been available for C#, and IMHO it's the single biggest reason C# failed to replace C++ for Windows client development.

<comment><USER14> Exactly. The redist is potentially annoying, but for my own projects I tend to statically link almost everything. It's not really a size thing, it's more of a "I don't want to bug my potential users to have to install a bunch of system altering things" viewpoint.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER17> So is this going to work on Linux?

</comment><comment><USER18> There was GCJ that used to do this for Java. Sadly it has been discontinued.

It is interesting how every old is new again, we went from AOT to JIT and Back to AOT again.

<comment><USER19> > There was GCJ that used to do this for Java. Sadly it has been discontinued.

There are lots of other AOT compilers for Java available.

> It is interesting how every old is new again, we went from AOT to JIT and > Back to AOT again.

Yep, we already went through this as everyone founded out P-Code wasn't fast enough. Then Anders Hejlsberg created Turbo Pascal.

</comment></comment><comment><USER20> It's interesting. It's more like a "static JIT" (BIT?) that does not account for the different data characteristics the instructions will process (which is something a JIT would/should do because it alters the actual program flow), but I find the "fast from the start" idea very compelling. I wonder how long will it take to Oracle (or the OpenJDK folks) to react to it.

</comment><comment><USER21> This could lead to a way to build a dynamic language on top of .NET and eventually be usable in iOS? I ask because: [http://docs.xamarin.com/guides/ios/advanced_topics/limitatio...](http://docs.xamarin.com/guides/ios/advanced_topics/limitations/) aka: No Dynamic Code Generation

</comment><comment><USER22> Only for Windows store? So who thinks walled gardens and feudalization are coming to all desktop OSes in the next 5 years?

In the future, a store / certificate authority will be able to arbitrarily revoke your right to run anything on your computer that isn't approved.

<comment><USER23> >In the future, a store / certificate authority will be able to arbitrarily revoke your right to run anything on your computer that isn't approved

We're already there with Web Apps and other SaaS "innovative" technologies.

</comment></comment><comment><USER24> This is great. I hope they make this available for web apps because we've got 45 second warmup time and CPU spamming due to the massive size of the work the JIT has to do when we deploy. Total pain.

I imagine this would help them keep costs down on Azure as well.

<comment><USER25> From my experience, much of an ASP.NET web app's start time is not so much the JIT-ing but _before_ that, when the ASP.NET runtime compiles pages/views (aspx/cshtml etc) into *.cs then DLLs. Pre-compiling can mitigate this.

Larger EF models can have quite an impact.

Also if you use New Relic, it can seriously affect startup time too.

<comment><USER24> Yes and no. We ship our views as content as we have a custom UI front end that isn't razor or asp.net. The startup time for us is compiling NH proxies and the fact that our bin dir is huge:

[http://imgur.com/EyjR5WH](http://imgur.com/EyjR5WH)

It takes forever for the JIT to actually compile all code paths in these assemblies.

There's no PDBs in there either. Our domain and NH maps consume 42Mb of that to give you an idea.

</comment></comment></comment><comment><USER26> Its truly a great thing. A single file deployment would be a tremendous improvement. Also removing the ease with which distributed applications can be decompiled helps as well.

Hopefully the marketing people let them spread it to all of their application types.

</comment><comment><USER27> No mention anywhere of ASP.NET. Is this going to help ASP.NET in any way?

<comment><USER28> I asked the same question. Seems like they are just trying to get something out of the mobile so far.

</comment></comment><comment><USER29> So is this the mysterious 'M#' technology revealed?

<comment><USER30> That's a language, this is a compiler tech.

<comment><USER29> That's already known. If you knew anything about 'M#' you'd realize these two have to be related somehow. That's the question.

<comment> apardoe-MSFT @BuckRogers, these two are related somehow. We've definitely benefitted from conversations with the M# people and they've likely benefitted from conversations with us. In fact, Joe Duffy once worked for our humble little .NET team :)

</comment></comment></comment></comment><comment><USER28> Microsoft: "We could speed up your server-side code, but instead we did speed up the slow windows mobile apps that nobody cares about."

<comment><USER31> here, educate yourself

[http://msdn.microsoft.com/en- us/library/6t9t5wcf(v=vs.110).a...](http://msdn.microsoft.com/en- us/library/6t9t5wcf\(v=vs.110\).aspx)

<comment><USER28> thanks, but no thanks. I won't go ngen just to speed up my start-up time on my web applications.

[http://stackoverflow.com/questions/385841/does-it-help-to- us...](http://stackoverflow.com/questions/385841/does-it-help-to-use-ngen)</comment></comment></comment>


I Ignored Trump News for a Week. Here's What I Learned - <AUTHOR> https://www.nytimes.com/2017/02/22/technology/trump-news-media-ignore.html?partner=IFTTT&_r=0 <comment><USER2> > The coverage those 1,000 people garnered last month totaled $721 million. In > other words, Mr. Trump gets about $100 million more in coverage than the > next 1,000 famous people put together.

Any publicity is publicity...

</comment><comment><USER3> I think someone needs to build a trump filter plugin.

kind of like an ad blocker but for trump and anti-trump news, comments, etc.</comment>


Stop supporting old releases - <AUTHOR> https://medium.com/@mikeal/stop-supporting-old-releases-70cfa0e04b0c <comment><USER2> > They keep old releases in their CI configuration and block PR's from being > merged if they don't work on older release lines.

If you are doing that, shame on you, that's not how stable and long-term- support works at all. If you backport, you backport on a best-effort basis, not on a must-have basis.

There is 0 sense in supporting old versions when you just backport all the new stuff into them anyway.

>You, in your GitHub project, probably don't have the time or resources to manage more than one release line of development.

That is certainly true. Over the whole essay I don't find much reason _not_ to have a LTS schedule.

I don't _have_ to backport all the stuff to older releases. My own policy is that any previous release will receive security patches as long as I can be made to care (usually about 1 year and in one case I support a 3 year old release of a project with security patches)

It is not _that_ much effort to patch security stuff. It doesn't take you away from your project for days, it costs you a few hours and some users of your project will be happier for it. That's all I want.

<comment><USER3> > I don't have to backport all the stuff to older releases. My own policy is > that any previous release will receive security patches

Besides it being easier, isn't _not_ porting feature patches the entire point of Long Term Support releases? People use LTS because they don't want any unexpected behaviour changes, only security updates.

<comment><USER2> Yeah it's basically the only way you should be doing LTS.

</comment></comment></comment><comment><USER4> I generally tow the line when it comes to software, but I do have a couple contrarian opinions and one of them is that LTS is really, really dumb. Not just for maintainers, for everyone.

LTS destroys your codebase. LTS allows mistakes like pushing state into your server that you didn't know was there. LTS makes it _much_ harder to upgrade because by the time you're moving off of, say, Ubuntu 12.04 the whole world has changed. LTS multiplies the number of things that can go wrong. LTS makes people think that the OS is going to be around forever so they don't architect their devices to be OS-updateable. IoT is bad now, but it's slowly getting worse too because half these devices are stuck on some out of date version of linux running some out of date version of Python.

All my servers run Ubuntu 17.10. Rails is on the latest version. Ruby is on the latest version. I don't pin any of my gems and every time I upgrade Ruby I upgrade the latest version of all the gems too.

This is only possible with extensive testing, and mistakes do get made here and there, but overall it's much, much easier handling these issues one at a time. The only thing I don't do is keep current on packages that I install via `apt` because I don't want to risk building from source.

<comment><USER5> Using Ubuntu has the big advantage that you dont have to maintain the packages yourself, so you just dont notice all the regressions that maintainer have to deal with on a daily basis.

Seeing fundamental things like glibc or gcc breaking almost every release makes you start to value LTS releases a bit more.

Disclaimer: Im maintainer myself and i feel your opinion is disrespectful towards the people who fix regressions for you (for free, even!).

<comment><USER4> There is no disrespect. I don't disrespect hardworking people trying to make the world better. This is just what I've found after writing software for decades. It's a viewpoint that I'm willing to change, but also one I think others should entertain so that all our software gets better and stays current.

Also, as I said in the original comment, I only lean on apt for a minority of things. Most stuff gets upgraded right away and you know what? I find and fix or communicate bugs because I'm on the bleeding edge. And I frankly do not see how my using apt invalidates my views on LTS. In the ruby world upgrading is almost never a pain because most of us keep current and test our codebases. I shouldn't be maintaining packages myself, and I do think that if the people behind Debian / Ubuntu / rando packages available took my worldview it would be easier to always be on the latest version and upgrading shit wouldn't be this giant headache all the time.

Common, glibc should break or break something every release. This is insanity.

<comment><USER6> In language package ecosystems (like Ruby's), _you_ decide when to push out a new release. You find that updating your lockfile breaks your code, so you put it off. You push out a few versions without updating the deps. Then, in one release, you update them all, fix all the problems that introduces, and then push out a new version that has the new deps and works with them.

OS package management doesn't work this way, because, for the most part, for almost the entire history of OSes, developers have had no control over the environment their application is running under. In a lot of cases (enterprise IT; academic/HPC mainframes; PaaSes) someone else has an upgrade schedule for the OS packages, and you don't get any say on when it happens. The OS updates, your package breaks, your problem. You can _maybe_ ask the ops department to hold off on updating, or have your PaaS "pin" your stack (until it becomes deprecated.) Either way, you're now vulnerable to security vulnerabilities while (hurriedly) working to push out the new release so that ops can get back to doing its job as normal.

LTS is a guarantee by the OS distributor that your ops staff _can_ update any package at any time (from the LTS repos, at least), and such updates _won 't_ break your deployed custom software. So LTS solves the cases above: enterprise/academic/HPC/PaaS ops staff can just upgrade as they will, without worry that anyone will tell them to hold off.

But the value of LTS goes even further: if updates are guaranteed by the distributor to not break your runtime environment, then you can actually _allow OS package upgrades to happen completely automatically and asynchronously_ to your development release schedule. The OS can just update _itself_. The OS distributor is now, themselves, part of your ops staff, ensuring that these updates aren't bothering anyone downstream of them. Your actual company doesn't have to care about the OS. It's _always_ going to be secure, because it's going to update as soon as vulnerabilities are discovered+patched, and you can just deploy your code at your own pace without worry.

Now, mind you, this all might sound quaint to people who bake containers for everything and treat said containers' host OS as immutable infrastructure. For these people, OS package security vulnerabilities aren't really something you can let "fix itself"; they're something that requires baking a new version of your container-image, just as app library-dependency security vulnerabilities would be. Relying on OS services rather than bundling a copy into your container-image is a trade-off in this case: you don't get to pin the version of a dependency to ensure its _exact_ behaviour, but in exchange, the distro will attempt to ensure that it will be free of security vulnerabilities while being _pretty much_ the same version you started with.

(Oh, and as a side-benefit, usually LTS package updates don't force system reboots. Recently even kernel updates don't, with fancy ksplice-based patch distribution channels. So LTS releases _also_ mean long individual-host uptimes, which is handy if you're running a service on the cheap and can't afford much horizontal scaling to manage load-balancing under rolling updates, but want five or more 9s of availability anyway. Try getting _that_ using immutable-infrastructure reboot-to-update VM images.)

</comment></comment></comment></comment><comment><USER7> Well said. Redis is almost 100 percent backward compatible back to the first release, so I never found a good reason to support old released. Want support? Upgrade... Of course this does not stop an infinite stream of bug reports about several years old releases.

<comment><USER8> I believe that the Angular team is also taking this approach. [1]

[1] At ng-conf 2017, the core team was asked whether they'd consider designating LTS releases, and the answer was essentially what you're saying here: They work very hard to be backward compatible, and encourage everyone to move _forward_ instead of getting stuck in the past.

<comment><USER9> Didn't they break everything between versions 1 and 2? If that's "backwards compatible" I hate to think what their LTS would have looked like.

<comment><USER10> They did, but quite honestly they should have just renamed the framework; Angular 1->2 is less of an upgrade and more of a completely new framework that happens to share the same name. It was a mistake imo, but one they made because Angular is a household name amongst web devs.

From what I understand, they've done a better job from Angular 2-5.

</comment></comment></comment></comment><comment><USER11> The destructive practice is not knowing how to write stable things. There is a small period at the beginning of a project where stability doesn't matter. There is a long period where instability will lead folks away.

<comment><USER12> > The destructive practice is not knowing how to write stable things.

Well, you can do it the Linux way, too: even if it is a bug, as long as fixing it breaks existing userland code, the fix gets reverted and the docs adjusted.

Compare this to anything except plain JS, jQuery and PHP - breakages all the time, everywhere, because no one values backward compatibility any more (python2=>3, for one, or whatever MS is choosing as the current framework to develop Windows applications now). This is the difference that MS took with the win32 layer and what made them successful - until they started ignoring BC in favor of loading new crap on consumers and enterprises alike every patchday.

<comment><USER13> I think it's dishonest to claim that Python does not value backwards compatibility because of the Python 2->3 update. That's a _single_ point of backwards-incompatibility in a project that has been going on for decades. (If you don't agree, please list all the backwards-incompatible changes that have been introduced in the years upon years since Python 3.0.)

</comment></comment></comment><comment><USER14> >They keep old releases in their CI configuration and block PR's from being merged if they don't work on older release lines.

Wait, people do that? If every PR lands on the next release _and_ on the LTS release, how is the LTS branch different from the latest release? Isn't the point of LTS that it stays the same (except bugs) and isn't evolving?

I must be missing something obvious here.

<comment><USER15> I think they're talking about code bases that use the software with the LTS, not the code base of the software with LTS itself. They test against latest and LTS, and your PR needs to work on both.

</comment></comment><comment><USER16> I think there's some ambiguity here around LTS for the project itself vs its dependencies, but as one concrete example, I support node 4 for an open source project I maintain, and I would defend that decision.

In my case, the only additional effort needed for node 4 is to use Array.prototype.indexOf instead of Array.prototype.includes, which is mildly annoying, and sometimes I forget and it causes a failure of the node 4 CI build, but really it's not that big of a deal. TypeScript handles the rest of the JS stuff, and the project doesn't use enough of the node API for those differences to matter. Other projects may different, but I think the right call is to drop support for old node versions when maintaining them is hard or because nobody is using them, not simply because they're old.

I want to use open source projects at work, not just in side projects, and at work we're on node 6 and always lag behind the latest node release by some amount, partly because upgrading node is a real project. We're a startup, not a massive enterprise, but it's still pragmatic to focus on real work instead of upgrading our dependencies all the time. If all of the open source projects out there only supported node 8, I think it would make them much less useful in the real world.

<comment><USER17> Why not just polyfill `Array.prototype.includes`? That's what my project does when the only features we care about missing from an old release are polyfillable.

        Object.defineProperty(Array.prototype, 'includes', { // eslint-disable-line no-extend-native
          writable: true, configurable: true,
          value: function (object) {
            return this.indexOf(object) !== -1;
          },
        });

Or if you're sure you and your libraries don't use any bad coding practices, you could even do:

        Array.prototype.includes = function (object) { // eslint-disable-line no-extend-native
          return this.indexOf(object) !== -1;
        }

<comment><USER16> That's what I'd do in an application, but it's bad manners to modify the global Array.prototype from a library, or to expect your parent application to provide such a polyfill, so usually it's best to just avoid polyfills in open source libraries.

</comment></comment></comment><comment><USER18> I've noticed this problem in the npm ecosystem pertaining to typescript typings. Typescript is evolving really quickly, each new release allows you to be more expressive, and there are stricter and stricter settings to take advantage of. It's fairly common for a third party library's typings to be incompatible with new typescript settings. The problem is that maintainers are reluctant to add support in the name of backwards compatibility. The only solution I've found in some cases is to completely override the library's typings myself locally.

</comment><comment><USER19> Outsourcing LTS support to (mostly) vendors is a big deal for Linux. When I write Linux code that needs a backport, I'll put a little bit of effort into making it easyish. Maybe I'll answer questions about backporting and try, on a not-very-much-effort basis, to help. This makes it way easier to keep the code clean.

</comment><comment><USER20> I think a reasonable business model would be to have original dev(s) push new versions and outsource LTS to some commercial organization, even with dual free/open source license for new releases and commercial one for support. If users don't want to pay for support, project is going to be dead in a few years anyway unless somebody wins a lottery/mines *coins/gets large inheritance $ etc.</comment>


Don't Hate Twitter. We Just Need an Alternative.(Part 1) - <AUTHOR> http://oonwoye.com/2011/03/13/dont-hate-twitter-we-just-need-an-alternative-part-1/ <comment><USER2> Dave Winer has been trying to do an open source version a while ago but didn't get too far — but I can really see the need for this. <http://scripting.com></comment>


When the DC-8 Went Supersonic (2011) - <AUTHOR> https://www.airspacemag.com/history-of-flight/i-was-there-when-the-dc-8-went-supersonic-27846699/?all <comment><USER2> Good story, and a great example of test pilot presence of mind as the crew discovers that the elevators don't work...

</comment><comment><USER3> I miss the DC-8. Always my favorite jet in my younger days. Those things felt like rockets taking off.

<comment><USER4> I have similar feelings about its descendant the MD-80. The power to weight ratio on takeoff was a lot of fun.

<comment><USER5> Yup. The MD-80 takeoff inspired confidence.

</comment></comment></comment><comment><USER6> Near criminally stupid though. Not only did they have issues with two separate control surfaces, a unplanned stall and a safety violation on takeoff, they did all of these things for a marketing piece establishing the plane was safe. This at a time where metal fatigue and structural load was not well understood, as the Europeans where finding out as their planes decompressed explosively midair.

There was a 747-SP that went supersonic by accident and was only saved by the crew deploying the landing gear to slow the plane down. He amount of damage was non trivial.

Someone will probably jump all over the critics of Douglas and point out Boeing's Tex Johnson's barrel row. 1) that was not endorsed by the company and 2) was a neutral G maneuver. 3) the company appropriately freaked and told him never to do that again.

We have occupational safety and standards operating procedures for a reason.

<comment><USER7> Since when is voluntary experimentation on a test rig, under controlled circumstances, criminally stupid? It's not like this was a passenger flight.

It would warrant criticism if the pilot tried it without informing the crew prior to takeoff. All participants entered into the activity with an understanding that they were risking their lives.

These people did it because they enjoyed the challenge, not to score points with corporate overlords or jockey for a raise and a promotion. The marketing angle was simply to provide cost justification and demonstrate that a perceptible reward would be earned with the risk undertaken.

<comment><USER6> That's a optimistic reading of the article. The article states it was for marketing reasons, and also states that they had several plan threating outcomes that were not planned for.

If it where in the context of understanding the plane's behavior at trans- sonic speeds, I can understand it, but that is not really given as a justification.

</comment></comment></comment><comment><USER8> What surprised me the most was that they did it on purpose!

<comment><USER9> Two reasons are pretty clear from the article. It was fun. And it could be sold to management as safety PR.

<comment><USER10> The engineering data alone from the flight was worth the risk. What they measured and learned during the flight probably gave the aircraft designers at Douglas priceless insights.

<comment><USER11> Modern aircraft undergo testing near the speed of sound to find issues as well. [https://youtu.be/rpP7hsuVuoE?t=1155](https://youtu.be/rpP7hsuVuoE?t=1155)

</comment></comment></comment></comment><comment><USER12> What does it mean when he says he pushed over into the dive more? Does that mean he went faster down?

<comment><USER13> Yes. To relieve stress on the stabilizer.

</comment></comment><comment><USER14> In a dive.

<comment><USER15> The biggest issue wouldn't have been designing a power system that could bring a jet to mach speeds. The bragging rights for them were that the plane survived the transition to mach 1.

<comment><USER16> Does something magically happen at Mach 1.0 that would compromise structural integrity significantly more than, say, Mach .99...9?

<comment><USER7> If you read the parts where they mention "buffeting" that's the dangerous part, where uneven airflow introduces instability, causing the airframe to rattle.

Buffeting occurs when the soundwaves of the noise of the craft and its motion directly affect the air as it flows across the surface of the plane.

This happens as the plane enters the shockwave of the sound barrier, and ceases when they accelerate beyond the speed of sound.

At and beyond Mach 1 the buffeting is behind the plane, and flight is smoother, with no rattling or shaking from the incidental turbulence.

It also happens when decelerating, although it's easier to decelerate safely through the buffeting quickly, since less time is spent in the shockwave, and a reduction in speed grants improved control.

<comment><USER16> I see, thanks for the explanation

</comment></comment></comment></comment></comment><comment><USER17> Queue up the Ryan Reynolds "But Why?" gif for this one I think.</comment>


Quarter of US iPhones 'unlocked' - <AUTHOR> http://news.bbc.co.uk/1/hi/business/7214873.stm

<comment><USER2> I think these statistics about how much money is lost in revenue is silly. Nobody cared to think if people would have bought the iPhone in the first place without knowing they were going to be unlockable.

</comment><comment><USER3> This means at&t sucks so bad that people risk bricking their iPhone to jailbreak it. I hope at&t gets the message.</comment>


Inside 'Hackerville,' Romania's Infamous Cyber Crime Hub [video] - <AUTHOR> http://motherboard.vice.com/read/inside-hackerville-romanias-infamous-cyber-crime-hub

<comment><USER2> This is stupid. Those guys are breaking e-mail accounts using exploits that were probably dumped on an IRC channel.

That city is renowned for cybercrime, but if you actually go beyond the media frenzy you find out that the vast majority are phishing and fake ebay accounts. They even brag about how they fool other people into buying fictional cars - I know this because I met some of these people.

There are no true hackers in HackersVille, only some people - journalists - who have almost no idea about how computers and the internet works but insist on refreshing this story every year.

<comment><USER3> This time has nothing to do with journalism, this is just a Norton campaign[0].

I think they present these scammers as "hackers" (or cyber criminals) only to scare some people, hoping they will buy (their) antivirus.

[0] [http://www.mostdangeroustown.com](http://www.mostdangeroustown.com)

</comment></comment><comment><USER4> Deliberately dramatic and made to seem like as if cyber criminals are as dangerous as the mafia with guns.

<comment><USER5> Heh, at least it's better than them happily typing away at keyboards while wearing ski-masks in a dimly lit room.

I thought Vice was 'good' journalism, turns out they pretty much sensationalise everything :(

<comment><USER6> Knowing the real Romania, I had the same revelation about Vice. These guys can go anywhere and pay some poor locals from some slums to say anything they want to hear, add some historic flashbacks (communist if possible) and urban mythology to it and bam !, they have a story to sell. Ridiculous

</comment></comment></comment><comment><USER7> It was interesting but lacking any technical details.

Are there any analysis on the attacks done by these individuals?

Something juicy like the analysis done by Symantec and Kaspersky.

<comment><USER3> Because most of them are just crackers. They use exploits found by real hackers.

<comment><USER8> this. Seems like it's all just script kiddies and social engineering. If you want to watch juicy hacking go for Geohot for instance. He does some crazy screencasts

<comment><USER9> Do you have any links? A cursory search didn't yield anything of value.

</comment></comment></comment></comment><comment><USER10> It's not so deep. The takeaway is that modern terrorism will go through wires. Today, the logistics needed to generate massive power failure able to damage severely the economy of all developed countries are arguably simpler than what's necessary to re-create a 9-11.

I think we should fear and get ready, unit testing and agile software are not enough. We need to make sure some systems are NOT reachable in any way via internet, we need formal methods and expensive secure designs.

I really hope terrorists never get smart enough to attack digital infrastructures.

<comment><USER11> There's enough fear going around to power a couple of wars. Fear is such a bad emotion to give in to. Unit testing and agile are _definitely_ not enough for mission critical systems like power grids and other infrastructure and airgapping certainly helps (but we've already seen that it is no guarantee for absolute security).

Why secure designs would be automatically 'expensive' is something I don't understand.

Terrorism is all about using fear for purposes of political pressure, simply don't give in to the fear and you've already won the battle, stay calm and clearheaded.

If terrorists really wanted to destabilize society they could easily do so but it would defeat their purpose, the one thing terrorists want you to be able to do is to continue to communicate and consume media, that's _their platform_.

</comment></comment><comment><USER12> this is just marketing

vice is selling sensationalism, and it's a far better story to pinpoint the hackers' lair on a map than to talk about real hacking. Real hacking comes from all over the world, including from governments and companies

norton is selling antivirus software, and it's in their interest to scare people instead of educate them

the funny thing is antiviruses don't really work against real hacking

understandint this better, it makes me wonder about news in general, how much do journalists care about the truth vs selling a story?

<comment><USER13> > how much do journalists care about the truth vs selling a story?

Not much. And it's the same the world over.

</comment></comment><comment><USER14> Lots of color effects. It's like Silent Hill, everything is ash gray / overcast.

<comment><USER6> This is anything but a documentary. It's a repackaged story about things happening 4-5 years ago. I never heard the term "hackerville" in romanian mass-media and I read it daily. If you google it you will see that it's a term coined by journalists to re-sell the same old story: ex-communist slums, "hackers" with russian accent, cyber-crime, dangers everywhere. It started with Wired in 2011, France24 in 2012 and now this..</comment></comment>


How Not to Build a Country: Canada's Late Soviet Pessimism - <AUTHOR> https://palladiummag.com/2019/09/19/how-not-to-build-a-country-canadas-late-soviet-pessimism/ <comment><USER3> While the article is kind of slog in the beginning to establish its context, this struck me as especially true/relevant:

"When innovative companies begin making decent profits, landlords raise the rents to adjust for the new ability to pay. As a result, these additional wages are neither reinvested, nor reflected in the disposable income of employees. This is the dynamic behind the mystery of stagnant wages. When workers in a particularly well-paid sector begin pouring into a city, landlords likewise raise the rent to absorb these incomes. It isn't gentrification, but absorption through monopoly power."

The housing affordability crisis is really a crisis of land owner cartels, especially in major urban centers. Short of some massive investment in public housing, there's not much that can be done to course correct.

<comment><USER4> That's not a cartel, that's a free market. It's not as if two or three landlords run the show.

<comment><USER3> If you bother to read the article, it makes heavy reference to Adam Smith's opposition to landlords and their rent-seeking because of the heavy drag they place on markets. They capture and enclose too much capital that could otherwise be used for dynamic and productive investment. He was as right then as he is now.

<comment><USER5> That does not describe a cartel -- it describes predatory pricing.

<comment><USER6> The cartel comes from the fact of how much wealthy landlords control local governments, who then make it onerously difficult to build the amount of housing that is actually needed. I don't know if this is the case in Vancouver but it is absolutely the case in California, with its absurd cases of a run- down laundry mat being declared a "historical property" to block redevelopment.

</comment></comment></comment></comment></comment><comment><USER7> """ But Canada is, and has always been, an oligarchy where the ruling families—the Saputos, Demarais, Reichmans, etc.—have relied on their own Brezhnevites to preserve their wealth by shielding them not just from competition, but from any kind of change.

The key to acquiring wealth in this country is creating bottlenecks by saturating public and private institutions with members of this class. """

So true. The general feeling that incompetence at these big companies has no consequence.

The depresssing and true: """This is how much a developer should make. We're not paying a penny more."

Sorry to say, but tech is not valued in Canada by Canadian companies. American companies operating in Canada have a better mindset.

<comment><USER8> > This is how much a developer should make. We're not paying a penny more.

This almost reads as if there is a cast system, where there is place for everyone to be comfortable with and shut up demanding more...

</comment></comment><comment><USER9> Reading this as someone who has moved from New Zealand to San Francisco, the parallels are depressing.

In New Zealand the price of housing has skyrocketed, and exists in a similar plane to Canada's housing market. We have the same issues of low productivity and relatively low wages as well.

There's a toxic cycle that's created. Boomers made all of their money in housing appreciation, and heavily encourage millennials to continue the cycle (which, taking the most optimistic view of it all, makes sense). But a house doesn't cost 2.5x your income now - it costs 8-10x. So you're married to a mortgage (which unlike America has its interest rate fixed for <5 years), have probably got a lot of your parents money invested as well (because you aren't earning enough to come up with a $200k down payment on your own).

Because real estate has 'proven' results, and the media make a lot of money advertising houses for sale, that's a lot of what you get told to do. As an individual you're so heavily indebted you can't afford to take risks, but at the same time, companies aren't trying to improve their productivity - <USER2> the best ROI has been in the property market. So wages suck too.

New Zealand is a bad place to be a young person. That's why I don't live there anymore. And I don't think I'll move back anytime soon unfortunately.

<comment><USER10> This generational change in house price to income ratios is also apparent in Britain and supply constrained US cities. It can be largely explained by the fall in mortgage interest rates from the 12-15% in the 80's to the 3-5% we see in the 2010's.

This windfall provided a massive generational wealth transfer from young to old, and with interest rates near the zero lower bound cannot be replicated. This makes housing a far worse bet for our generation, even for those of us earning sufficiently more than our parents to be able to take a shot at home ownership.

<comment><USER9> 100% agreed. It won't end well, and politicians being politicians (and voters being voters), we're going to continue this mad show as long as possible, ensuing we get the worst possible outcome here.

The weird bit is that San Francisco prices make _more_ sense than where I grew up (suburban New Zealand). Sure a house in SF might cost $1.2m but two people working in tech can expect to make $250-300k all in by their early thirties. That's only $200k more than a house in New Zealand, but you're working with an income that's easily 2x the size.

<comment><USER10> A $250K household income is on the 96 percentile for San Francisco. Working in tech gives us a slightly warped perspective.

Moving from Britain to the US I've seen the income of my profession as a software engineer move from the 75th to 90th percentile and the variance of the income distribution widen so an income of the 90th percentile earns 2.6x rather than 2.0x the median. We're far richer here than we were at home.

</comment></comment></comment></comment><comment><USER11> _Landlordism in cities is (correctly) blamed for a worsening of income inequality._

While I agree that landlordism tends to increase income inequality -- especially in the form Vancouver suffers, where protests convince the city to reject the construction of new housing even when the land is already appropriately zoned and the proposed building complies with the approved local development plan -- but it's wrong to refer to a _worsening_ of income inequality.

Income inequality in Canada increased substantially through the 1980s and 1990s, but it peaked around 2004-2007 (depending on exactly which measure you use) and has been steadily declining since then.

<comment><USER12> _Wealth_ equality on the other hand...

<comment><USER11> Right, that's a completely different issue. (And much harder to measure, never mind address. Even defining it is hard; do you count the NPV of pensions, for example?)

<comment><USER12> I don't see why you wouldn't. An easy way to see if something is valuable (wealth), take it away from someone and observe their reaction.

</comment></comment></comment></comment><comment><USER13> This is pretty accurate. Rent seeking in Canada is at an extreme, monopolies are maintained through excessive government regulation, cartels in real estate as well as many industries are definitely a thing and almost the whole country is under-employed.

Don't have a ton of time ATM but we're in dire need of deregulating a lot of industries and breaking up cartels.

<comment><USER7> Could not agree more! There is a general malaise and slowness in companies/industries I have had to interact with (Telco, Banking).

</comment></comment><comment> drevil-v2 Having lived through a Soviet inspired bureaucracy where the wait times to get a phone line was years, getting a car could take up to 5 years; this article is spot on. Eerily familiar. That same tingling of dread from decades ago washed over me haha.

Everything was mandated by a bureaucrat, how many factories there could be, how many goods they could produce. There was no concept of supply and demand, instead there was five year plan from the central government and that was what would be implemented regardless of the ground reality.

When people got a phone line installed in their house, the neighbours would come over to marvel as if visiting a new born baby.

When my uncle got his allotment for a scooter after two years, he distributed sweets to his co-workers. It was a great occasion.

<comment><USER14> This part of the article was a bit silly -- Canada is nothing like this. I feel like he tied his own experiences with late-soviet bureaucracy to his frustrations with conservative Canadian business climate; but the two are not analogous really.

Canada is a market economy with very low corporate taxes and when compared to European economies regulation is actually very light. Our business norms and regulations are tied in most part very closely to the United States.

But the investment culture is very conservative and the economy is tied excessively to resource extraction.

And yes, there is a long history of a few families having strong dominance over everything, and of businesses/companies gaining monopolistic positions through regulation. An example of this is the wine industry in Ontario -- I could go on a long rant about that... but I'll restrain myself.

</comment></comment><comment><USER14> Unfortunately it's deep in the Canadian business community DNA; the family compact, the Hudson's Bay Company, whatever... Exempted from population density, rapid growth, and revolutionary fervor of our neighbours to the south, we were a place where colonial money could just sit and go stale.

It was the fur industry and logging then, now it's crappy oil from the tar sands that sells for little more than it costs to dig it up; but nobody in Calgary has the balls to admit it.

I have American friends who talk about Canada in glowing terms as a place without the same corruption as the US. It's just a different kind of corruption, that this article aludes to throughout.

And yes, nothing ever gets done. Everything goes over budget. Not a problem confined to B.C. by any means.

</comment><comment><USER15> I am reading an interesting book now: Why nations fail [https://en.m.wikipedia.org/wiki/Why_Nations_Fail](https://en.m.wikipedia.org/wiki/Why_Nations_Fail)

The author discusses that for a country to be successful there must be institutions that encourage working hard and entrepreneurship. More, the political system should be organised in a way that stimulates creation and support of such institutions. The negative consequences for politicians supporting oligarchy must be worse than for ones who introduces changes that can improve lives of regular people.

My guess the problem is not in real estate speculations - it is just consequences of underlying system inefficiencies.

I see Canada has good educational system, right? But as they say in the article, there is not a lot of motivation and places for smart engineers to do their best.

There are barriers to make changes in many areas like medicine, real estate (based on the article).

The government seems to be in a situation where due to corruption and lobbies it does not do appropriate changes. They know what to do, but they do not find it good for them personally. Oligarchy wants to keep their positions unchallenged.

It is just my guess and pure speculation, I do not know much about Canada.

EDIT: added more on concequences

</comment><comment><USER16> The success of a cities and nations has always dependent on a couple of variables: 1\. Human capital (increasing size and quality) 2\. Cheap real estate (ever decreasing share of real estate costs as an input of value creation machinery) 3\. Cheap energy costs

In the U.S. and in most developed countries, we've had (1), in some cases (3) but (2) is become scarce.

In my opinion, there are very few modern cities that are able to provide cheap housing these days. It requires an activist government fighting two very powerful forces: existing home owners and corporate landlords. Truth is that the lobby of those interest groups are way more powerful than low income renters.

The other problem is that expanding the housing stock is not sufficient, governments have to provide basic services: water, public transportation access, sewage, etc.

Who is going to pay for them? In most cases, the cost is paid via property taxes (existing homeowners and corporate landlords)

The truth is that we have disincentivized the creation of new housing stock and until we fix the underlying issues of bringing more supply to the market, this issue will continue to worsen.

[https://www.zillow.com/research/new-construction- shortgage-2...](https://www.zillow.com/research/new-construction- shortgage-20991/)

<comment><USER9> I don't agree. Coming from NZ to America, I am amazed at how cheap housing is (outside of a few select areas - California, New York and a few major urban metros), and the fact that you can fix your interest rates for the length of the entire loan. America has many problems - and California definitely has a housing crisis, but that's not true for the country at large.

</comment></comment><comment><USER14> I feel like Kevin O'Leary's boat crash (with fatality) on the Georgian Bay last month is a metaphor for the entire country's economy:

Arrogant baby boomers driving around in luxury in the pitch black night, with the lights out, running into each other on the lake -- and then shirking all responsibility.

<comment><USER17> For a moment I thought the witch is dead, turns out O'Leary wasn't one of the victims.

</comment></comment><comment><USER18> A pretty accurate but damning portrayal of the economy in Canada. I wonder how smaller but more successful economies like Sweden or Israel manage to consistently build great companies?

<comment><USER19> Usually it is not because of, but in spite of their governments. With the mention that Israel has some great companies, but Sweden is on a strong descending trend.

</comment></comment><comment><USER20> If supply proves too difficult to increase, why not try reducing demand? Or course that would be unpopular with the infinite GDP growth folks but sooner or later will have to be confronted. Seems like the entire political spectrum supports infinite growth even if it manifests in different ways in different political parties.

<comment><USER21> A good way to reduce demand is to both vastly increase the amount of identity reported in real estate (especially for out of country buyers) as well as to have foreign ownership taxes.

it would crash the BC economy hard though. There's very little left there that isn't driven by foreign purchases. (quite a lot of it illegal in their home countries, eg the USA)

<comment><USER22> I thought money from China (legal and illegal), not America, was driving BC real estate.

</comment></comment></comment><comment><USER23> One interesting solution to home ownership and rent seeking might be to spread the rent increase revenue around. In BC at least its common to disallow sublets. Whereas in NY its more or less allowed by law. This means as the rent goes up, land owners are the only ones who have the ability to make money.

</comment><comment><USER24> We're in the middle of an election right now and housing is an important issue. However, most promises will make things worse rather than better. For example, the Conservatives' plan to allow thirty year mortgages will do more to increase prices and indebtedness then to lower payments.

<comment><USER11> I'm honestly not sure which is worse, the Conservative plan to allow 30 year mortgages or the Liberal plan to have the government loan people money for their downpayments...

<comment><USER25> Both plans seem geared to draw the votes of current homeowners, also more likely to vote in elections.

<comment><USER11> I agree. And it makes me sad that parties are deliberately adopting policies which they know are bad policy (they hire economists who tell them this!) because they prioritize electoral success over doing what's good for the country.

<comment><USER25> The better solution is to get more people involved in politics, then we will realize that if everyone votes, no one benefits therefore government should be limited.

I can dream....

</comment></comment></comment></comment></comment><comment><USER26> Y'all don't know the meaning of cartel. It's being thrown around here like beads at mardis gras. I'm just sure I don't want to see most of you without shirts on.

A cartel is an agreement between organizations/people _throughout a supply chain_. Landowners twisting their mustaches and rubbing their hands together do not make a cartel. Rule of thumb, at least 3 steps in a supply chain. What they would be, is a trust. They're at the same level of the supply chain working together. If you're going to cry "late stage capitalism", for fuck's sake actually know how capitalism works and how to cheat the system properly. There are rules on how to cheat in capitalism. A 10 minute youtube video won't do that for you or the rantings of a crazy frenchman.

<comment><USER27> Citation requested.

Counterpoint, definition 2:

[https://www.merriam-webster.com/dictionary/cartel](https://www.merriam- webster.com/dictionary/cartel)</comment></comment>


Ancient Roots of BNF - <AUTHOR> https://blogs.scientificamerican.com/roots-of-unity/a-feat-of-mathematical-eponymy/ <comment><USER2> Interesting article.

There is both left and right recursion in the definition of <number>, but this EBNF (Wirth notation) uses iteration only:

number = digit { digit } [ "." digit { digit } ] .</comment>


Winners for Wayra UK accelerator announced - <AUTHOR> http://wayra.org/en/blog/first-winners-wayra-uk

<comment><USER2> Woop woop :-) I am a co-founder in one of the 16 teams. These last three days have been amazing. I am at work with a hang over this morning and it feels like It was all just a dream. I am very much looking forward to meeting all the other teams I didn't have time to talk to yet and of course let's not forget the 14 that didn't get in.

Now the real work begins!</comment>