u/korran

I would like to see people who deploy these models in irresponsible environments take some legal liability for their decisions. If the model companies were liable for every dumb decision their customers made, they would be bankrupt.

This implementation is optimized for the constraints of Google's enormous mixed-language codebase. The "weak reasons" are likely non-negotiable internally, based on decades of experience using protobuf at scale.

Jinja doesn't do context aware escaping, it just blindly uses standard HTML escape sequences which are not safe in every context. Read the blog post I linked to as to why this is dangerous.

Are there any Rust template engines that do context-aware escaping?

There is always more demand than supply of subsidized housing, and the folks who "aren't poor enough" lose out.

The priority has to be to get the real market rate of housing down by doing whatever it takes to build 20% more homes than exist today ASAP. Even if we have to relax building codes, eliminate parking requirements, and stop fussing about whether the new homes are "pretty enough".

Folks who purchased homes at an unsustainable price are victims of bad policy and bad advice. There's no way out of this disaster that doesn't involve a lot of pain for innocent people. Regardless, the most pressing priority must be to provide housing for upcoming generations that is affordable for families with median wages and no pre-existing wealth, as that is the only way Canada can avoid a dystopian future. Perhaps we can tweak bankruptcy law and social services to be kinder to those who got caught up in all the insanity and made bad choices.

A correctly functioning democratic government must be biased towards today's labor force rather than yesterday's capital.

Consider talking to your Supervisor to let them know your feelings; their perception of public opinion does shape policy.

Yeah, I wouldn't be surprised if poor decisions made by people working remotely from an isolated box are responsible for many of the supply chain issues we are suffering from globally.

I'm interested.

Ideally, I prefer an API that conforms to the language standard. However, with C++ things are not so simple.

Microsoft could have standardized their C++ ABI, and used that for WinRT. This would be a huge undertaking. The memory layout of the STL classes would have to be rigidly defined for the next 20 years, preventing future improvements and optimizations in the C++ runtime. This decision would also be almost catastrophic to implementors of other languages (in particular the CLR), who would need to reimplement a good chunk of the C++ runtime in order to bind to the native API. (Imagine what it takes to bind to a method that takes std::vector<std::string> as one of its arguments)

In comparison, WinRT has a relatively simple ABI, designed to be consumed easily by many different languages.

If you were really determined, you could probably access WinRT exclusively through the low-level COM interfaces using standard C++. This would be quite the painful experience, probably quite similar to using Win32/COM today. :) I'd rather use C++/CX, get my platform-specific code written as quickly as possible, and then spend the extra time on the parts of my application that actually solve problems.

I don't really see the problem with a platform vendor using proprietary extensions to a language to create a proprietary API. You only need to use this stuff on the edges of your application, which are already going to be tied closely to windows.

This is pretty much the same as what Apple did with Objective C++. I have no trouble writing cross platform C++ applications that dip into Objective C++ when they need to interface with the operating system.

I completely agree, but I'm also thinking about scenarios such as having a mutex in shared memory being stuck in a locked state when the process holding the lock is killed. If the entire machine goes down, it's not as much of a concern.

When running on Linux, relying on a graceful shutdown for correctness is a huge mistake. If the kernel is starved for resources, it can kill my process, even if my process is not the cause of the starvation. Thus, in order to be correct, my software needs to be able to recover from abrubt termination at any time.

Unfortunately, the correctness of this functionality is notoriously hard to verify, especially when dealing with persistent state. If I completely eliminate the 'graceful shutdown' code path, at least the recovery logic will be excercised frequently and bugs will become more visible over time.

Considering that I'm talking only about AJAX requests here, I'm not sure how it could possibly show up in a referrer header. SSL is a good cure for nosy proxies :)

I could limit the cookie to my web-application's HTML pages, leaving the API URLs cookie-free.

The problem with CSRF is not how my application accesses the data, but how other websites can. The danger is that another site can access my REST service by including my service's URL as a script tag in his page:

<!--On attacker's site-->
<script "http://www.mysite.foo/rest/customer-details" type="text/javascript"></script>

Even though the attacker is not in my domain, his website can make GET requests to my API with the user's cookies. The technique described in the article allows him to then access my pure JSON data with a clever Javascript hack.

Your suggestions do nothing to prevent this attack.

I'm not sure I really like the practice on relying on complex Javascript semantics for security. Why don't we stop using cookies, and instead just pass the session ID in the request parameters for these sorts of AJAX requests?

Having spent the last year or so working on a significant WPF application, I've concluded that the current implementation (as of .NET 4.0) has serious architectural issues. As I am sure most WPF developers are aware, the documentation is extremely lacking when it comes to the core framework. I've been forced to decompile the IL to understand why something isn't working more times than I can count. And when I do, I am usually amazed at the unnecessary complexity and low quality of the code.

Performance, even after all the improvements in 4.0, is still abysmal. Something as simple as a DataGrid or ListView that updates 20 rows 5 times a second almost completely saturates the CPU. I can do this same task in Chrome, IE9, or Firefox, updating several thousand rows, using significantly less resources.

For some parts of my application, I have been forced to bypass WPF and go straight to Direct3D. The preferred mechanism for doing this, D3DImage, has a ton of performance overhead over simply creating an HWND and doing it the old fashioned way.

Don't get me wrong, there's a lot of fantistic ideas behind WPF and XAML. Data binding, in particular, is pretty powerful. Microsoft could probably repair a lot of the problems with the current implementation, but I suspect it would be a huge development effort. The Windows team has a library that works well today (Trident 6). It has better performance for many common use-cases, and likely better architecture, so it's not too surprising that they're using that over WPF.

It will be difficult to implement C#'s reified generics in an efficient way on the JVM. Also, the performance advantages of using value types on the CLR will not translate to the JVM.

Indeed. However, I believe that it is wise to make performant choices when readability is not at stake, regardless of whether the code is in the hot path or not.

For example, if the problem calls for some sort of data structure to store key-value pairs (and retrieves them up in a random order), I will use a hash table rather than iterating through a linked list. The readability of the code is the same or higher than the linked list implementation, and it doesn't cost me any extra development time to choose the correct data structure during development. If I choose the incorrect data structure, it will take me extra time to change the implementation if it becomes a problem.

Not sure I agree. All the game consoles are big-endian.

Can't PowerPC run in either mode?

One word: Libraries! Porting x264 from C to the JVM would be extremely painful.

Ok, fair enough, I forgot about self modifying code. Hopefully one day somebody will come up with a safe way to enable a similar sort of optimization.

As for portability, I'm not hugely concerned. Most libraries that I want to use will compile fine on just about any architecture, and I can always link to LLVM from my apps to generate code for whatever platform I need.

Endianess is an issue, even with LLVM, but at this point I think it's safe to say that little-endian has won the war, and that it is unlikely for any new consumer-class architectures to pop up that do not support little-endian.

Unfortunately, C++/CLI generates unsafe IL that can do direct memory access through pointers. It would be extremely stupid to run untrusted C++/CLI code from the internet, as it can do everything that native code running outside a sandbox can do.

Why is Google reinventing the wheel here? What benefits does this bring to end-users, apart from yet another plugin/technology we need to support?

I think the idea is that eventually you will need no other plugins. Just native client. Flash and Java plugins, the Javascript runtime, hell, maybe even the HTML renderer itself, they can all be sitting out on the internet as NaCL "libraries", and your application just includes them as it would include a Javascript file today.