fh973

Problem with Linux is that in order to support arm you don't just have to build for the architecture but also for a specific distribution and version.

You are able to attach the block devices, but local file systems do not support being mounted on more than one host.

For that you need to use a cluster file system, but that's a different beast.

One important aspect that should be mentioned is that OpenEBS is essentially a block storage system (think virtual hard drives, which need to be formatted with dfs/ext4) and by its nature can't expose the same files to multiple pods.

Ceph(FS) and other distributed file systems allow you to access your data from any number of machines. Also they provide faster and more robust failover as they don't have to unplug the virtual hard drive and repair the local file system.

That's covered in Java by escape analysis and allocation on the stack.

Depends on the problem. Codes that run on supercomputers need low latency communication and access to a lot of data. Think physical simulations.

I can half answer that and hope somebody can complete the story.

What you have in your bank account is not digital cash. It's effectively a note that the bank owes you cash.

This may sound like a technical detail but as far as I understood without physical money there would be no bank accounts. That's what I always wondered about: how could an economy go 100 percent electronic banking, if banking is built on the existence of physical cash?

This is the missing link. With those accounts you actually would be able to own electronic cash.

That said I have no idea how this would work in practice. Maybe you would have the payment option to pay with this electronic cash. But why would you pick one over the other?

They're begging for the European legislation to require mobility of email addresses as we have for mobile phone numbers.

For the uninitiated: Rook is a deployment tool for Ceph and a few databases on Kubernetes. The heavy lifting is done by Ceph, the name is only mentioned in passing in the 10th paragraph.

Does it have a replaceable battery?

Great to see you here!

I understand your unit of smallest write is a blob. How large are blobs? How does their identifier look like?

a) I wonder in which sense HDFS was ever the most popular DFS. You could argue that it is not even a DFS, because it is not a general purpose / POSIX file system. In 2012 there was Lustre, GlusterFS, GPFS, ... Not many DFS were built since 2012.

b) It is completely unclear how the replication works, and which properties it has (split-brain safe?). From what it states (see citation), the "repair" is not automatic.

Their architecture descriptions starts with a strawman:

> Usually distributed file systems split each file into chunks, a central master keeps a mapping of filenames, chunk indices to chunk handles, and also which chunks each chunk server has.

> The main drawback is that the central master can't handle many small files efficiently, and since all read requests need to go through the chunk master, so it might not scale well for many concurrent users.

The chunk server architecture has been first put into production with the Google File System AFAIK. And it has been designed specifically for large files (what search needed at that time). So no surprise.

But that's only one architecture for a DFS. There are also block-based DFS (like GPFS), object-based DFS (Lustre.), cluster file systems (OCFS), and other architectures. They exhibit other characteristics.

Telling from the architecture and Wiki, it does not seem to be a file system at its core, but an object store with a file translation layer. One of the core problems of this approach is that in-place updates usually mean read-modify-write (if the object store has immutable objects, like most have, with Ceph being a notable exception).

From the replication page:

> If one replica is missing, there are no automatic repair right away. This is to prevent over replication due to transient volume sever failures or disconnections. In stead, the volume will just become readonly. For any new writes, just assign a different file id to a different volume.

This sounds like the architecture and implementation is still pretty basic. Distributed storage without redundancy (working redundancy!) is not that interesting.

Sorry to be that critical (great that someone writes a distributed file system!), but I think it is important to add some context. And the seaweed auther seems to have problems with bold statements either...

Disclaimer: I also work on a distributed file system (with unified access via S3 ;)

During my last London trip, I had the impression that they mostly employ young people from all over Europe. I suspect they will all be gone end of year.

I guess the room does not leave many options, but he picked the one with one window from behind where he sits.

I think Google couldn't do better, even if they wanted to.

The reason is the engineering culture and the promotion system. People expect to switch to new projects, and work towards to a promotion within 2-3 years. This shows in all products, and presumalby also the reason for the deprecation. New people come on the project, want and need to do a major overhaul, and do not have resource or incentives to support the old stuff.

The other half is that most projects are done efficiently by relatively small groups of engineers. I remember that Android Market was still a few people in MTV, with no payment possibilities outside of the US, when Apple already had significant revenue from apps. And that shows everywhere. I'd argue Google is incapable of tackling projects that require more than a few hundred people for more than 2-3 years.

But as a billion dollar company, that does not work. Throwing money at obvious new billion dollar opportunities like Microsoft did with gaming and cloud, and following through over 5 years is not possible for Google.

It seems a bit that the big players also realize that making money off their technology investments would be nice.

Here we have the interest of IBM/Redhat that as a services company benefits from an as open as possible model, whereas Google as a product company notices that their hugely successful k8s play does not turn into business for their cloud product as intended.

That's surprising. I was under the impression that landing outside of an airfield is only permitted in a few states and parts of Canada? In Europe it's generally forbidden (with the sailplane exception of course).

The S3 protocol needs MD5 hashes, which these benchmarks don't cover. A Xeon core can do that with a couple of hundred MB/s. As it's a continuous hash of the whole object, this limits S3 performance.

I guess AWS does not care that much about single stream S3 performance but will optimize for costs.

The barrier is actually bigger than just money: for an EV certificate you need to prove that you are a registered business. So there is a name and an address behind it, which is kind of a barrier for malware.

There is a huge difference of what kind of identity is established: Let's Encrypt tells you basically that you are actually talking to the right server, whereas EV certs for signing binaries tell you which company that actually exists in the real world owns the certificate.

Not that simple to just pay. You need an EV certificate (https://en.m.wikipedia.org/wiki/Extended_Validation_Certific...), which in turn needs a verified business address.

Not a good plan to distribute malware without going through the effort of faking a legitimate business aswell.

The democratization of music. Seems like this is what you get when the marketing departments don't determine what's listened to.

I beg to differ, at least for the genres I have some attachment.

Kids that are into hip-hop still listen to 90s hip-hop, now called golden era.

On the other side 90s electronic music has great stuff, but the field has much advanced in quality and depth.

Can you do without an encoder for legs? Maybe attach an IMU like you do for gimbals? Or measure current?

That's interesting, and suggested by the movie. However I wonder how that works in Europe for inner city locations. Here in Germany both in large and small cities, I can't recall any that I can imagine being owned by McDonald's.

Much simpler to use as a user. I'd say the k8s API is very much over designed and has artifacts that you don't find in other job description languages. Or can anyone explain me the need for StorageClasses, PVCs and PVs with CSI mixins just to access some files?

As a scheduler it's much more powerful in capabilities, scalability and performance. It was designed to react to different workload demands in huge clusters very quickly. Imagine a data center goes offline and you need to spin up the search engine while killing a map reduce with 20k workers. A borg cluster is war zone, priorities and quotas win.

Yes. Not directly Borg but another infrastructure component does.

No, it's not that easy. It may also mean your transmission live-locks because your receiving state machine is waiting for more data that never arrives.

Yes, it needs a failure detection mechanism, because next time it might be a cosmic ray. But encryption and authentication alone doesn't help necessarily.

Manhattan 69,467 per square mile (Wikipedia).

Yes, I am also not enthusiastic about the crypto part, but then if it prevents people from spoofing signals, it is probably a good decision.

The wikipedia suggests they use standard hardware components?