zootm

> For spring boot, the default is actually logback.

I did not know this, thanks for letting me know!

> I update aggressively on my own projects to stay on top of changes and keep the effort related to mitigating compatibility issues at a minimum. A nice side effect is that you get all the latest security, performance, and other fixes. In my experience, updates get harder the further you fall behind.

This is absolutely a best practice, though I think people struggle with it for all sorts of reasons. In general one of the downsides of maintaining a diverse codebase is that this constant update cycle becomes more and more difficult, and it's one of the things that I find drives towards more consistent tooling within a team.

> I work with a lot of customers running ancient versions of whatever for no other reason than that they seem a combination of fearful, ignorant, and indifferent about what will break because they can't be bothered to even try.

While I agree this is something people need to get over, we have to take some blame for this as an industry. A lot of people have bad experiences with upstream Shiny Object Syndrome.

Using logging facades means that libraries don't need to update -- which is great -- but libraries were never directly vulnerable anyway. log4j is, to my knowledge, still by far the most common actual implementation of logging in the Java ecosystem. The assertion that it's not popular for logging only holds if you assume that logging facades are logging implementations, which they are not.

My completely-unverified guess would be that there are more people immune to this issue because they never migrated past log4j 1.x than there are who are immune because they picked up Logback or something similar.

> You shouldn't need to pour over code to figure it out.

This is true but as sibling comments have pointed out, a lot of other software you might be deploying without having written or configured the logging for are written in Java.

Looks like the paper referenced is from May, if you have a subscription to Nature: https://www.nature.com/articles/s41586-020-2278-9

“Third party”. In this case it just means “not Amazon”.

I've worked at Amazon since 2007 and I can confirm it has gotten a lot better over that time, especially more recently.

I have, in the deep deep past, experienced serious strife with the older policies, and obviously nothing is perfect, but it's gotten to the point where I don't really think about the policy.

I think it's worth noting that the paper is from 1992, where much of the work you reference (such as widespread use of overloading in Haskell) won't have existed yet.

I don't think it's unreasonable to point out that some of the assertions didn't stand the test of time, but I've (maybe unfairly?) read your comment as critical of the paper despite context.

Work on the specification stopped in 2010 but it's not been removed from the browsers that supported it.

I think this is mostly answered in the README. This is probably the most relevant section:

> The structure validation is simplistic by necessity, as it defers to the type system: a few elements will have one or more required children, and any element which accepts children will have a restriction on the type of the children, usually a broad group as defined by the HTML spec. Many elements have restrictions on children of children, or require a particular ordering of optional elements, which isn't currently validated.

It's not complete or thorough at present.

Regarding your link: I'm impressed someone took the time to write a DTD for HTML5!

Isn't the former what Mozilla Persona was trying to provide? A shame that was canned.

If you go to the Privacy section of the iOS app it's mentioned at the bottom with a link to the webpage ("Further customise your privacy..."). Not ideal you can't do it from within the app though.

This isn't the case, he works for Amazon. Unless he also works for Intel but that seems unlikely.

Edit: Just to make this clearer you can see his email in the Signed-off-by of the patch under discussion: https://lkml.org/lkml/2018/1/20/163

I had a look in Software Update and apparently iOS 11.2 is now available (not as a Beta release). Since people were reporting the Beta didn't have the issue, maybe Apple just released it?

Possibly he was using this poll data: https://twitter.com/DRMacIver/status/746810127584464896

...but I don't know what the primary source of that is.

Edit: Sorry about multiple broken links, I was klutz-editing this on my phone.

> Those languages used to introduce mutable wrappers and not a "to_string()" method.

Yes! This is similar to, say, StringBuilder in Java. The difference is that ownership is intertwined with the type here. Strings are always owned, and as such you can choose to mutate them. String slices (references) are not owned by you (you borrow them), so you can't do anything that would be memory unsafe. You can borrow a mutable slice of the String (like a reference to the backing array), which you can alter in-place but you cannot do anything that would require reallocation (Strings being growable was mentioned earlier -- mutable slices are not). Slices which come from string literals are always immutable.

For probably-obvious reasons you can only take one mutable reference at once, while you can have as many immutable references as you like. Taking a mutable reference also prevents you taking any immutable references at the same time: https://doc.rust-lang.org/book/references-and-borrowing.html...

In my own experience this takes a bit of time to get used to, and in some cases the rules are still quite frustrating. People with more experience of the language report that they get used to it, though.

> Is that similar to the dynamics of uniqueness types?

I believe it's similar, but I'm not super-familiar with uniqueness types. This SO answer looks good: http://stackoverflow.com/questions/26309081/how-do-rusts-own...

If you have a string slice (&str) you need to convert it to a String you own before you can mutate it, yes. In some other languages strings are always immutable, and mutating them requires creating a copy. In Rust if you own the memory (and haven't given out any immutable references to anyone), you can mutate it.

String literals are an interesting case for the reason mentioned in the earlier comment: they reference memory that no code "owns", as in-place mutation of the executable would be unsafe.

Some languages have mutable strings but these are usually unsafe if used concurrently, or require locks. In Rust this is modeled in the type/borrow system.

I think we're running out of good names for things, especially since Spark uses Snappy (compression) itself.

It is time to build a tool on top of SnappyData called Spark.

I'm led to believe the Glasgow TMU is pretty lively as well, although I've never been.

Filtering out "bitcoin" should do the job.

I'm finding the fact that almost every page in the CIA site's 6-12 section has the same "classroom" stock photo to be inexplicably unnerving.

> When working with JSON, you must load the whole JSON document before you can start processing it.

This is not the case; JSON is every bit as amenable to streaming as XML, in my experience. Fewer implementations may support that, of course, but that's not really the fault of JSON. The Jackson parser for Java, for example, has a complete streaming API.

I think I heard the Amazon-supplied ePub converter can work better sometimes, but I haven't tried it. It may be the one on this page: http://www.amazon.com/gp/feature.html?ie=UTF8&docId=1000...

People focus on these because they are usually exploitable through applets; as such they pose a direct threat to users. The recent issues have been mostly irrelevant to "enterprise systems" since so few use Java's sandboxing, and it's typically easy and quick for developers to respond.

If Python was runnable in browsers and widely installed I suspect it would be treated differently in media.

So does Subversion :-)

This is true, although I find the default body text size in Bootstrap way too small, and often wonder if others do too. It seems to fit the "text wedged into elements of a Web tool" use-case it originates from better than longer body text.

There was also http://www.doineedajacket.com/, but that seems to have gone ad-crazy to the point where I can't find the result.

I think cluster instances are always HVM, not sure about high IO.

I believe it's because the "normal". EC2 instances are paravirtualised through Xen, whereas the types listed are hardware virtualisation. Not sure though.

Also see also RecordStream: https://github.com/benbernard/RecordStream

Someone mentioned jsawk in a sibling comment, too.

Tagged "satire" in case that isn't clear (I certainly missed it at first).

Would it be possible for them to just rely on the commodity chip and PIN readers that most banks (in Europe, or at least the UK where I am) use for 2 factor auth for online banking?