HN user

tnorgaard

226 karma
Posts4
Comments25
View on HN

This talk seems set out to prove that "XML is Bad". Yes XML-DSig isn't great with XPaths, but most of these attack vectors has been known for 10 years. There is probably a reason why the vulnerabilities found where in software not commonly used, e.g. SAP. Many of the things possible with XML and UBL simply isn't available in protobuf, json. How would you digitally sign a Json document and embed the signature in the document?

The article nor the talk appear to reference the XML standard that EN 16931 is built upon: Universal Business Language, https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=... - which is freely available. Examples can be found here: https://github.com/Tradeshift/tradeshift-ubl-examples/tree/m... . It is a good standard and yes it's complex, but it is not complicated by accident. I would any day recommend UBL over IDOC, Tradacom, EDIFACT and the likes.

As having implemented EDIFACT parsers and translation layers, Universal Business Language (Oasis UBL) is a bliss to work with. Yes, it's a big standard and looks scary when starting out with it, but it is very well designed for a complicated world.

Super interesting compiling pg, I assume, with same as the zfs block size! It was always on our todo to try, but never got around to it. If possible, what block size did you end up with? Have you tried zfs direct io in 2.3.x, if so, could you share any findings? Thanks for sharing - and cool website!

If I may make an suggestion: Instead of a static json file, read at boot, I'd suggest passing the feature flags down per request as a header, or a pointer to the set of feature flag. So that all systems for a given request, observe the same features. Just my 2 cents.

According to this IBM study [2]/Wiki article [0], the probability is much higher - per the study with 128GiB of memory it is every 1h 25min.

There was an anecdote[1] about a Power Mac cluster at a university, which basically couldn't get past boot because the memory errors was so frequent.

[0] https://en.wikipedia.org/wiki/Cosmic_ray#Effect_on_electroni... [1] https://spectrum.ieee.org/computing/hardware/how-to-kill-a-s... [2] http://www.pld.ttu.ee/IAF0030/curtis.pdf

I see there is a few posts repeating the common interpretation that glyphosate is not dangerous because it only targets metabolic pathway only animals has, so for the sake of discussion here is another viewpoint: https://www.youtube.com/watch?v=kVolljHmqEs (disregard the clickbait title), summary: Glyphosate is not bad for your body, but it does kill everything in your stomach, and that is not so awesome.

We run with ZFS over LUKS encrypted volumes in production on AWS ephemeral disks and have done so in over two years on Ubuntu 14.04 and 16.04. The major issue for us has been getting the startup order right, as timing issues does occur once you have many instances. To solve this, we use upstart (14.04) and systemd (16.04) together with Puppet to control the ordering.

Performance wise it does fairly well, our benchmarks shows ~10-15% decrease on random 8kb IO (14.04).

We are definitely looking forward to ZFS native encryption!

Please stop spreading this misinformed statement. I assume you are referring to the ZFS ARC (Adaptive Replacement Cache). It works in much the same way as a regular Linux page cache. It does not take much more memory (if you disable prefetch) and will only use what is available/idle. We use Linux with ZFS on production systems with as low as 1GB memory. We stopped counting the times it has saved the day. :-)

ECC is a nice to have, but ZFS does not have special requirement over say a regular page cache. The only difference is that ZFS will discovery bit-flips instead of just ignoring them as ext4 or xfs would do.

We have been running ZFS on Linux in production since April 2015 on over 1500 instances in AWS EC2 with Ubuntu 14.04 and 16.04. Only one kernel panic observed so far, on a Jenkins/CI instance, but that was due to Jenkins doing magic on ZFS mounts, believing it was a Solaris ZFS mount.

In our opinion, when we made the switch, it was much more important to trust the integrity of the data, than any possible kernel panic.

Have you considered Rackspace's OnMetal products or other IaaS providers that run bare metal, such as Joyent Public Cloud? If you are in such a rush, I'll suggest to factor in both the migration risk and the time to deliver said hardware. Fx the Joyent Public Cloud will allow you to have a mixed private/public cloud as their IaaS software, Triton, is open source and you can run it in your own hardware. Note: I'm not familiar with anybody running Ceph on illumos LX containers although.

Interestingly, this was what Alan Kay was advocating for on the web: "A bytecode VM og something like X for graphics" [1].

When Lars Bak and Kasper Lund launched Dart [2], I found it sad that they weren't more bold - left CSS and the DOM alone, and created an alternative Content-Type. So you can choose to Accept 'application/magic-bytecode' [3] before text/html, if your client supports so. Sadly, we ended up with Web Assembly, which by the few talks I've seen, appears to only cater to that of graphic/game developers, with no support for dynamic or OO languages.

[1] https://www.youtube.com/watch?v=FvmTSpJU-Xc [2] https://www.dartlang.org [3] Or in Dart lingo, a VM snapshot.

Good questions you raise, nhaehnle.

First of, I don't try to pretend to be a scholar in economics, so please bare with me.

That a capital system contains people/entities that accumulate wealth is exactly why I finished off with the Thomas Piketty comment. His very interesting book, Capital in the 21st Century, argues that our current system favours capital owners and we should tax capital, not income.

About labour being displaced, I can recommend Second Machine Age by Andrew McAfee and Erik Brynjolfsson, however it does not contain silver bullets. :-)

I can only theorize on what Stephen Hawkings meant with his answer, but to me it didn't look like a general critic of capital, but more the system we have now.

To be fair, it's not really capitalism he is arguing against, but rather Special Interest groups misusing their position in a capitalistic system. Milton Friedman, a Nobel Prize winning liberal / "capitalist", spoke against monopolies and Special Interest groups for ~30 years [1].

I would have loved to see a Milton Friedman and Thomas Piketty debate although. :-)

[1] https://www.youtube.com/watch?v=Y2T2Ee8zm6s

HTML is done 11 years ago

I think we can build it however closed or open we would like it to be. The sharing of source code I suspect is more social than technical, therefore I don't expect much change.

Java Applets, Flash, SilverLight always was at a disadvantage, not being native to the browser runtime. Startup time and the need for a "plugin" hurt them. And they all kinda sucked in their own way. I hoped for a long time that Dart / native DartVM to Chrome could make a stride, but sadly they were fighting uphill battle against the sheer volume of JS developers resisting change. I'm convinced that it's never about the language[1], but the VM and it's abstraction layer. We need a layer that we can compile JavaScript(/HTML/CSS), Scala, Haskell, C#, F# etc. down to, not more languages.

I wonder how many man-years has been wasted on vertically aligning div's inside a div. :)

[1] Guy Steele, amazing talk on "Growing a Language", https://www.youtube.com/watch?v=_ahvzDzKdB0

HTML is done 11 years ago

Maybe we should listen to Alan Kay's proposal: https://youtu.be/FvmTSpJU-Xc?t=1082.

It might be bad example, but if the Java SE runtime libraries was just a dependency like any other mvn artifact (module), Sun / Oracle would for example have been in a position to introduce immutability to the Collections framework and fix crazy other stuff[1] without breaking backward compatibility. But now we are stuck with those legacies forever[2], since they standardized on a too high level abstraction and choose fewer layers. For Java's, luckily they had layer underneath - JVM byte code, which is why I predict Java is still relevant for many years going forward.

The next generation of WWW needs to a very low common abstraction, e.g. bytecode. Something similar to X Windows.

[1] See Effective Java Puzzlers. [2] Project Jigsaw might change that.