lambda

Since the MtGox fiasco, I've never bothered trying to liquidate any more of my Bitcoin, and instead just occasionally use it to pay for things which accept direct Bitcoin payment.

I'd be a lot happier with a trustworthy, audited exchange.

If there are smaller exchanges that couldn't deal with the regulation, they probably also can't deal with security, keeping enough secure reserves to be able to pay out in the case of losses, auditing both their security and finances to ensure that they stay healthy and liquidate gracefully if they ever run into financial trouble.

I'm curious about how this would work if the designers have to use developer tools to do the final spit-and-polish.

I don't know about how other places do it, but what I'm familiar with is that a UI mockup is sketched out and requirements given to the developer, the developer implements something but in the process finds issues with the design as specified and iterates a bit while doing so, and eventually you have something that is functional but somewhat ugly because the original sketch was not specific enough or didn't anticipate some issues that came up or the like, and then finally you give it back to the designer to do the spit-and-polish.

In some cases, the spit-and-polish can be a lot of work, because you've used some new widgets that you don't already have standard styles and graphics for, or maybe it's your first app with a new toolkit and so you need to figure out how to get your branding and style to work with it.

For designers I've worked with, CSS is their favorite tool for styling, and they prefer UI tools for spit-and-polish layout tweaks. Are you saying that they should just deal with having to learn how to do all of that embedded in code, or that they should just hand off their assets and suggestions to the developers and the developers have to do the final spit-and-polish work?

I'm a fuddy-duddy still doing UI in GTK and Qt, I haven't kept up in trends in web and mobile design, but I know that when our developers do the layout and design it comes out awful and unusable, but luckily with GTK and Qt we can just hand it off to our designer after the basic functionality is in place and he can do some layout tweaking with Glade or Qt Designer, and is comfortable with working with CSS to provide us with custom widget styling and images, and then he sends it back to us and we clean up the results and merge it.

All of the Flutter examples seem to have the UI written entirely in code, both layout and styling, and I don't think he'd be comfortable with that. You may note that we send it to him, he tweaks it, and sends it back to us to merge; we've never been able to teach him Git, but that's OK, because we don't expect him to teach us Photoshop and design.

So, I'm just wondering if Flutter is intended to always be like this, with the whole UI specified in executable code that needs to be compiled and run for each iteration, or if it is intended to add a way to separate out the design parts (layout and styling) in a way that they can be worked on at least somewhat independently of the code?

I know that there is IDE support for hot reload, which may be OK for a designer to work with, but I'm always a little skeptical of that since most developers I know use VIM or Emacs and not IDEs, so sometimes IDE tooling setup can break, and once a project gets complicated, the toolchain setup for running from within an IDE can get hard to install. The nice thing about Glade or Qt Designer is that they can work with purely declarative formats so that you don't need to worry about having to have your designer get the full toolchain installed.

Really makes me cringe to read some of that text, but that was high school.

Oh, and even more eye-bleeding is the page I ran for a Nomic that I was in, and webmaster (sorry, "Secretarylet of the Revolution in charge of Web Pages") for: http://www.nomic.net/deadgames/macronomic/. I don't know what I was thinking when picking that particular shade of red; red made sense, but I'm sure that even with the palettes available back then, I could have picked one a bit less painful.

Did you read the article?

> Here it is! Not exactly our target of 512KB of RAM but 768KB is getting pretty close. Some microcontrollers already have more than that amount of available on-chip SRAM.

768 KB of RAM, plus a MB or two for the text sections which are in flash, is not bad. Not quite at the target, a system with 512 KB of ram and 2 MB of flash, but it's close.

Yes, that's why my phrasing used "at this moment." At this moment, millenials are around an age range of 20-35 years old, give or take a bit depending on the very fact that you point out, there aren't well defined boundaries and the exact age range could vary. I was very careful to include "at this moment" in my phrasing, for the reason that you point out. I didn't bother to hedge about the unclear boundaries of the millenial generation, since that wasn't the topic at hand, but yes, these terms are somewhat vague.

The actual article cited simply discussed the nationwide birthrate at different points in time; it didn't talk about particular generations.

Given that millenials are currently the generation that are of prime child-bearing age, it's pretty clear what the original poster meant "people of child bearing age right now, who happen to be millenials, are having less children than those of child bearing age at any point since the great depression."

The original phrasing was humorously incorrect, I just thought that asking for clarification was a bit much, since it was pretty clear what they meant to say, it was just a funny mistaken phrasing.

Really? After reading all of the articles in this series (the original about porting to Rust, the rebuttal about optimizing JavaScript, and this one)?

I'm more familiar with Rust than JavaScript, but I found that other than the algorithmic optimization, the rest of the JavaScript optimizations were very non-obvious in order to achieve an effect that is entirely natural in Rust.

There's no need to be careful to avoid particular types of function calls, since there are no dynamic variadic function calls in Rust. There's no need to resort to using the equivalent of `eval` for monomorphization, it's a natural feature of the language. There's no need to do manual memory management by encoding values into typed arrays of integers; you can simply allocate vectors of structs, borrow references, and so on.

These are all things that had significant cost in JS, and needed to be worked around via some intensive profiling and knowledge of how JIT engines work, but just doing things naturally in Rust leads to a pretty much zero-cost solution.

It's true that if you want to really get into the nitty-gritty of micro-optimization in Rust, you need to learn some more and do things like profiling and inspecting the generated code to see what optimizations the compiler was able to apply or not.

But the Rust rewrite of source maps did none of that; they just rewrote it in fairly idiomatic Rust, and achieved a similar speedup to what a JIT engineer armed with a profiler, a deep knowledge of what affects how well a JIT works, and a willingness to do manual memory management in typed arrays was able to do.

> Having worked/interacted with a lot of people working with Rust on different experience levels, most of them (that includes me) don't have a deep knowledge of what Rust concept maps to a specific concept with which performance implications

What parts of Rust do you feel like you don't understand the performance implications of? I feel like the mental model for performance is relatively similar to C or C++, with relatively few things that would surprise you if you're familiar with modern C++ (in fact, a lot fewer performance surprises than modern C++ offers, in addition to the extra safety).

That may just be for the proof of concept.

There are websites which allow users to customize themes of certain pages; such at Tumblr and Reddit. I believe these allow custom CSS. There are probably plenty of other places where it may be possible to inject CSS but not JavaScript.

So, it's worth demonstrating the vulnerability, even if the current way of distributing it only really makes sense for testing purposes.

A lot of times I am looking for images which are in the public domain, and for which if I go to the page in question, I have to then sort through dozens of images to find the one I had been looking at already in the search.

Here's an example. I've just done a search, found an image that I want to view larger, the image is long since in the public domain, but when I click on "visit" I get a page with a list of text links that I now have to sort through to find the full image:

https://images.google.com/imgres?imgurl=http%3A%2F%2Fwww.kee...

Edit to add:

Now that I look closer, I notice that Google is actually embedding the original image, instead of a preview (they load a low-res preview, and then replace that with a hotlinked image), so you can just right click and choose "view image" now to work around this.

I guess that's OK for people who are technically inclined enough to know that you can do that.

You could have some protocol by which sites indicated that it can't be linked; but then everyone who embeds a Getty image would have to change their site to adopt that, and that would probably involve Getty having to change their licensing terms to require that, which would be a huge hassle for their customers who probably wouldn't bother doing it because it's difficult and doesn't help them out at all.

Or you'd have to do some kind of watermark embedding.

Anyhow, while it would be technically possible to do one of these things, I suspect that legally it was just a lot simpler to get Google to remove the feature.

I think that just having the CLICOLOR option would be reasonable, for enabling or disabling color to a TTY, but CLICOLOR_FORCE is more problematic.

Looks like this is already supported by more software; rather than an n+1 standard (https://xkcd.com/927/), why not use this one instead?

But it brings with it the full flexibility of a general purpose programming language which makes it a lot easier to make parameterizable designs which can be more easily reused.

For the rest; yeah, it looks like it's pretty eye-bleeding and hacked together from decades worth of odd little one-off tools: http://opencircuitdesign.com/qflow/, https://opencores.org/howto/eda, https://chitlesh.fedorapeople.org/papers/FEL12ReleaseNotes.p...

That's because it pretty much is. CSS standardization and implementation has been significantly lagging what people want to do with it, so people have had to resort to hacks for a long time.

For instance, early versions of CSS were only really designed for formatting a single column of text, with possible floating images and tables. There was nothing in CSS designed for global layout; but people eventually found that you could use floats for that purpose, which was hacky but worked.

The first tool actually designed for global page layout is CSS grid, which has only recently been implemented by the latest versions of all of the major browsers. In the intervening time, you have also been able to use layout: table and flex-box, both of which give you some of the things you want but aren't quite designed for it, so the peg shape has been getting a little closer but not quite there until grid was implemented.

So for 20 years or so, people have been using tools not really designed for their jobs; there's been a lot of work at hammering those square pegs into those round holes.

Of course, now people aren't just looking to lay out static sites; rich, desktop-style web apps are a thing. flex-box is a tool for doing traditional GUI style layouts, but there's still nothing available for CSS modularization allowing rich controls to be built without being affected by other global page styles. There is a work in progress; web components and shadow DOM, but as of now that's only available in Chrome and in development in Firefox.

Anyhow, it's getting better, but it is still lagging behind what people are actually doing substantially. I think that with CSS grid, plus all of the other functionality that now exists, it would be a lot easier nowadays to have design tools which could generate fairly reasonable CSS, but I don't know of tools that take advantage of this yet.

That is, what RustBelt analyzes right now is a language which has an analogue to Rust's borrow checker, but is much much simpler overall; and they ported Rust's implementation of several types of shared mutable or owned references over to this language to verify them.

There is a lot of Rust outside of these few caveats that hasn't been covered; these are just the things which could be in scope of the RustBelt work that haven't been covered by it.

Here are a few things that there's ongoing work on that you would want to finish before saying you were confident in a using a formally verified language:

1. The memory model. This gives a formal definition of what kinds of aliasing assumptions the compiler is able to make about raw pointers in `unsafe` code. This is being worked on here: https://github.com/nikomatsakis/rust-memory-model 2. The borrow checker. While the RustBelt work shows that a much simpler borrow checker can be sound, Rust's borrow checker has to deal with a much more complicated language, and there are few known soundness bugs in it (discussed elswhere in this thread). You'd want that to be formally modeled and verified. 3. The type system. Rust has a fairly full featured type system, so you want to ensure that's sound 4. The compiler itself. Even once you have sound code in a sound language, you need to make sure that the compiler follows the rules and compiles it correctly. 5. Any libraries or code that you are using which might be using `unsafe`. The RustBelt work so far has done so for a few core primitives, as well as a couple of third-party libraries, but of course you'd want to re-do this work against the full language (or a real-world subset, not LambdaRust that this paper used) and include any other libraries that you might need to use.

So, I'd say that there's a good chance that the RustBelt work could be extended to include one or more of these listed features before all of the rest of the above has been done. It will be a while before you could have a usable, verified subset of Rust, but once you do I think it could be a good alternative to something like SPARK, or development in C following extremely stringent rules and compiling with CompCert.

I'm not sure how common a pattern that is. Many people like to avoid trait objects and just parameterize the function on a type bounded by the trait in that case. And impl Trait is replacing some of the other cases in which you had to return an allocated trait object.

Anyhow, you're right, I was wrong that people couldn't be using trait objects in an embedded context with no allocator, but I also think it's perfectly reasonable to write in a subset of Rust in which you don't use trait objects at all.

The RustBelt work addressed one of the big open questions; is it possible to treat `unsafe` code in a modular fashion, or does all analysis of unsafe code have to consider all possible interactions with all other modules which use `unsafe` code as well?

That was in many ways quite a big question about the design of Rust; can you prove or very each module which uses `unsafe` independently?

The borrow checker, on the other hand, is an entirely local analysis. It can get quite complex, especially as you allow for more fine-grained borrow checking to make it convenient to use compound objects, and introduce non-lexical lifetimes which help reduce the number of restrictions on what you can do, but since it's entirely local, it's a much more tractable problem.

I think that it would be good to eventually formalize the full Rust borrow checker, and of course it's always good to fix these soundness bugs, but there are some more important open questions right now like fully specifying Rust's memory model (https://github.com/nikomatsakis/rust-memory-model) so it's possible to know what kinds of aliasing you can actually do in `unsafe` code, and which will be safe even under future versions of the compiler.

The RustBelt work so far is just a nice foundation getting Rust to be more formally analyzed and specified. There's a lot of work left to be done.

Embedded code in Rust almost always avoids 1, 2, 3, and 4. Arc is used for freeing dynamically allocated memory when all references, including across threads, are dropped, but if you're running without dynamic memory allocation, you don't need that. Trait objects also require allocation. Embedded targets also generally don't implement stack unwinding, and stack unwinding can be disabled on other targets as well; it's really only most useful in larger applications in which you want some threads to be able to continue running even if another thread panics. Automatic destruction can be fairly easily avoided if you're running without an allocator, as it is mostly used for freeing such allocated memory, as well as a few things like file handles and the like.

The things covered in 5 might be harder to avoid, but also more likely to be amenable to being covered by further versions of the RustBelt work.

So yes, using a subset of Rust without these features is quite feasible, and often done when working in embedded (aka no_std) code.

I don't know SPARK Ada that well, but I believe it has similar constraints of no dynamic allocation. If you can do without dynamic allocation in Rust, many of the problematic features wouldn't be used.

This helps demonstrate that one of the fundamental design goals of Rust, have a simple but limited system of borrowing built into the language, and allow more complex forms of managing reference types safely built on top of it as library features using `unsafe`, is a fundamentally sound design. In other words, you don't have to treat the language and all libraries using `unsafe` as one large system that you need to prove soundness of, but you can do modular proofs of the core language, and each library that adds a new type of memory and reference management, independently.

Those bugs you reference are simply bugs in Rust's borrow checker. The language used for the RustBelt paper, LambdaRust, is a language that is much simpler than Rust itself, making the borrow checking much easier but the language not as convenient to use (it is not intended to be used at all, just to act as a model of Rust).

The things you reference are simply bugs, but because of the fairly expressive syntax that Rust offers actually getting the borrow checker right can be be difficult in some cases.

I don't think that there are any theoretical concerns about the ability to write a correct borrow checker, just practical issues with the current implementation not correctly handling certain cases.

There are newer helmet technologies that are supposed to absorb more of the impact, and in particular allow some slippage of the shell to reduce rotation, which can be one of the most harmful types of movement:

https://www.popularmechanics.com/adventure/sports/news/a2797...

Whether these will be effective at preventing CTE, or only preventing concussions, is hard to say without a lot more data.

In states which haven't, you can make too much to qualify for Medicaid, but too little to qualify for Obamacare subsidies: http://money.cnn.com/2014/04/21/news/economy/obamacare-medic...

This happened because the Supreme Court ruled that states couldn't be compelled to expand Medicaid to cover the gap, which the original legislation had depended on to make the plan work. So states which did not expand Medicaid have an income range in which you can't get Medicaid or Obamacare subsidies.

If you don't have a permanent address, up to date ID, and a bank account, and a job, many of these programs may not be available to you.

But I believe these counts do not include welfare programs other than those that give you cash (like Social Security benefits including disability). Other programs offer services or restricted forms of payment, which cannot be used for saving, for purchasing other things you might need like gas or transportation, and so on.

Either way, it's fairly inefficient; either they were paid for doing no work, or they were not paid and may leave for better jobs or morale destroyed due to that.

I believe there is a name for this belief, Mammonism comes to mind.

However, the military is entirely part of the federal government, as are many other organizations. In the case of not having a budget, the government is required to shut down all functions that are not essential for safety and security. So things like the military, the TSA, and so on can continue to function, but office workers doing jobs like allocating the funding for highway construction are furloughed, put on temporary unpaid leave from their jobs.

This is, of course, terrible for the efficient functioning of government; when the impasse is over, they will have to come back to their jobs and try to catch up. Oh, and in the time leading up to the shutdown, many of them would have been busy preparing for the shutdown, documenting which functions would be considered essential and thus able to continue during the shutdown; because the deadline was no surprise, and there had been many temporary funding bills leading up to this point, there was always a pretty high chance that this shutdown would happen.

Of course, this inefficiency plays well into the politics of one of the parties, who hold a religious belief that private enterprise is always more efficient than government, and so playing games like this that increase its inefficiency help to sell their case and get government functions sold off to private enterprise, who just so happen, in so many cases, to be some of the largest donors to campaigns of this particular party.

https://ishoudinireadyyet.com/

This gives a much greater ability to iterate rapidly on new layout and styling details, polyfill for specifications that aren't widely implemented yet, and hook into some parts of the browser stack that you previously just had to use as is and trust that if you need a new feature, it would eventually be specified and/or implemented.

I think this article does the best job of explaining the whole effort:

https://www.smashingmagazine.com/2016/03/houdini-maybe-the-m...