asharp

Remember that there's a big difference between an aftermarket mod and setting up a factory to build purpose built electric cars. You have lots of additional regulatory/cap costs/etc. to bear.

Also keep in mind that they are making entirely (or mostly) new types of vehicles, ie. the tricycle. And design doesn't come cheap.

You can fairly easily spot most common protocols by seeing what they 1) Say to you without you prodding them or 2) Respond when you hit them with random data.

My guess is that they're using it as a cheap way to tell the difference between most of the common protocols. (ie. ssh vs. openvpn vs. https, etc.)

Or that they initially thought it was unisex but when they actually tried it on the female model the IK came out looking wrong in some obscure case. Or it had unexpected tearing issues. Or they had a fixed release date and couldn't get the female version finished in time, or .....

Still a stupid decision. They probably should have just scrubbed both. I'd wait until we get word back from the publisher before trying to work out what actually happened and if it was, in any way, dishonerable.

There is no such thing as unlimited.

However, if you were to take p(x) as the pdf of people needing exactly X storage and take the standard assumption that the integral over it's domain (0->infinity) = 1, then you can work out the expected amount of storage required per customer (integral of xp(x) over it's domain). Now as long as the cost required to host that expected amount of storage is less then the amount they are being paid, well then, they still make money.

But what usually happens is that they take various 'measures' to cut off the right tail of the pdf to make it more profitable. That's dishonest.

There are hard realtime patches to linux and have been since 2.4

I'd imagine that there would be some previously tested (say in aerospace) linux derivative that they'd be building off.

To be perfectly honest though, I don't know why they arn't using one of the few really good commercial hard real time unix kernels that you use for, say, UAV's and such.

The BWT is also rather interesting https://en.wikipedia.org/wiki/Burrows%E2%80%93Wheeler_transf... . An efficient implementation is fairly simple, but not at all intuitive.

Also remember find's -print0 and xargs -0 so that you can deal with all filenames.

Or if the default was that things were private, and that only specific things become public.

But then you have the same problem of "If nobody sets things to be public, there's nothing to read, so no incentive to be a user".

I wonder why nobody really calls it corruption.

Interesting, but why don't you use a udev rule?

Something like KERNEL=="sdg", RUN+="/usr/bin/madagascar" and then you have madagascar check the environment variable ACTION for a 'remove', and when you see that run shutdown? (or just write straight into sysreq for instant poweroff)

Yes and no.

Remember the interface between the vm and hypervisor is standardised and it is running many other functionaly identical vms. Also remember that platform they are running on is usually homogeneous, very well maintained, monitored, and understood.

Also keep in mind that with 'hardware issues' you can reploy onto another machine in minutes, rather then having to wait for say a replacement part from dell/etc. Your standard procedures should come into play in both cases (Failing to a secondary server, bringing a tertiary server into standby, etc.)

For certain workloads it deals ok, but yeah, I'd fully agree with you.

On the other hand, there are plenty of clouds out there that have reasonable IOP performance, so it's not as though it's a monopoly.

You scale out hardware layer by finding optimal hardware and scaling out on that.

The major problem with their 'scale out' chart is that that particular hardware is far from optimal hence costing far more then it should.

Keep in mind that screwing with syscalls is an AWS thing, not a virtualisation thing. They make fsync wierd for good reason though, and they really don't have much they can do.

What you care about at any reasonable scale (ie. the point at which costs matter) is $/serviced request. That usually ends up being dominated either in $/cpu cycle or $/iop. The current problem is that most cloud platforms suck iops which makes them far more expencive then they really should be.

Cloud vs. dedi vs. colo in terms of raw prices though, depends entirely on your price of money and the price you can negotiate with your provider.

Saying that you can't get IOPS on AWS is like saying that your machinegun sucks at grating cheese. It's really not meant to do that.

But that's fine as AWS isn't the only cloud platform out there, and some are actually desgined to take data intensive workloads.

Saying that because fsync() doesn't work in AWS that it won't work 'in the cloud' is much like saying that because you can't take a cheap sedan to the bush that a 4wd can't possibly exist.

Google can't exist (well) on top of AWS as AWS is designed for the deployment of (qusi)stateless applications. Saying that you can't build a data intensive application on top of it is like saying that your machinegun sucks at grating cheese.

OVM was designed to run a search engine origionally (darkmatr, now defunct due to lack of comparitive profitability), so you could quite easily build google on top of it. It wouldn't surprise me if google would work really well on top of that stack.

Say what?

It's an 85-140W thermal envelope chip, with 16 very fast cores (iirc, AMD vs. Intel TDP). That's in a completely different planet to a 1W sluggish(ish) ARM core.

Or, slightly more to the point: Oak ridge is making a supercomputer using these chips. These are designed to be very fast. They are not designed to be low energy in the ARM sense of the word.

These are, iirc. designed to be used in visualised server (cloud) and other high compute environments.

Good point. I'm not sure what most of that stuff was doing in hardware in the first place, tbh. Haproxy has been better then hardware load balancing for a long time.

What is interesting is the move off cisco's proprietary routing algorithms and into more standard quogga/etc.

You know an agreeable (not quite sure about good) idea when you realise that something you've been implementing yourself has been done by somebody else better.

Bravo.

Hey,

There isn't any nice way to get in contact with you via the website, and you didn't leave an email address here. What's the best way to get in contact with you?

What's sad is that 1tb/second isn't actually that fast anymore.

I can get over 1tb/second of switching cap in a switch that costs a few grand. Mind, I can't do this with Ethernet yet, but then again Ethernet was never meant to go above 10 megs.

Hey Boyter,

Is your whois info correct on searchco.de? If so, you should have gotten an email from me. If not, would you mind emailing me?

Thanks, Alex.

What you want is lighttpd. Lighty is designed for streaming/static content/etc. and it's simple to use.

Yeah, there are a whole bunch of things you could try, but i think a standard Gaussian blur on the edges would solve your problem.

Basically, yeah.

All lower end devices end up with basically same batch of ASIC, anyway just due to cost.

Most switch stuff, however basically comes down to needing more hardware. Cam costs a certain amount, packet buffers cost a certain amount (Or wormhole switching silicon costs a certain amount), etc. None of that you can ever really move into software. At least not decently.

Arista switches are switches with the actual data path in silicon but with the CNC running on an onboard processor running linux.

It's cool, it's both stupidly fast (wormhole switched, etc) and very configurable. Just costs an arm and a leg.

Cool. I'm Alex from OrionVM. I just sent you a message on your contact form. If you have any questions, don't hesitate to email me. Talk to you soon.

That's what stable marriage is for. With some reasonable heuristic it should just give you the best partial ordering, which when flattened into a total ordering should give you the most likely picture.

How do you calculate your certainty?

Spot the 'bayes killing' spam :)