Live data from Hacker News

We are still early with the cloud

erikbern.com

171–180 of 202 posts

Re: We are still early with the cloud

#171

Earlier quoted context omitted.

That is far, far more than transferring a byte of data. Educate me. It's much more meaningful and useful than "something simple" "running little functions floating in the void" which just sounds like some vapid marketing pitch. That was a quick response to what I thought would be better than administrating a UNIX system on an Amazon machine. Don't be an ass. I've no experience with the real distributed computing syst…

> Educate me. Not sure if I'm being trolled... It finds a remote machine by name, and routes a connection to it. It authenticates and establishes a secure connection with the machine. It sends a command to the remote machine, the remote machine executes it, and the result is returned. It then puts the result into a form that can be used programmatically by the local shell. > That was a quick response to what I though…

I'm being trolled by someone who finds a DNS lookup and an encrypted TCP connection to send a textual command to another machine is somehow impressive, rather than entirely basic and, again, unimpressive.

It then puts the result into a form that can be used programmatically by the local shell.

That does sound better than returns one octet with two well-defined values, sure.

And already the expert. Impressive.

I know UNIX is shit with a legion of cultists.

Hey, if we live in the best of all possible worlds, explain the market dominance of Windows. Did MicroSoft give Windows away for nothing, to poor unsuspecting university students who decided to hack on it instead of learn what a real computer is, until none remained?

Re: We are still early with the cloud

#172

Earlier quoted context omitted.

I don't use k8s or whatever garbage gets thrown around nowadays. I well remember my disgust when I learned AWS was just using UNIX virtual machines or whatever, rather than something simple, such as allowing people to run little functions floating in the void. I know nothing about AWS, but I've not been mistaken, right?

In the end, almost everything runs on some kind of OS. All those little functions in the void also have to run in an OS, but this is abstracted away from the user.

Congratulations on understanding what an abstraction is. Do I need to worry about the transistors or individual atoms in a computer? Why should UNIX be the right level of abstraction forever?

Re: We are still early with the cloud

#173
post #50

Earlier quoted context omitted.

Quoted post unavailable.

Okay, tell me how you do it much better in k8s

    # ssh user@k8s.machine "test -f fileThatExists"
    # echo $?
    0
Gee it's like nobody realizes that k8s is just unix machines too, only difference is instead of a program in the whole OS listening on a port, it's a container... And _gasp_ you can deploy containers to listen to any port you want and have those containers do anything you want... Wow.

Re: We are still early with the cloud

#174
post #30

Earlier quoted context omitted.

People forget that a good deal of “cloud” logic existed in a form on mainframes as well.

Mainframes are very expensive. You can buy mainframe with very fast CPU and RAM interconnect and scale it by buying more hardware. Or you can spend 100x less and buy a number of server blades. Interconnect will be very slow, so you can't just run some kind of abstracted OS, you need to run separate OS on every server blade, you need to design your software with that slow interconnect in mind. But in the end it's stil…

That's why I both hope Oxide Computers succeed and worry they may not.

They are effectively building a mini computer. The smallest unit you can buy from them is an entire rack. Modified rackmount hardware with better software to make it more cohesive.

I really hope they go to half-racks, but I've no idea how you'd stack them.

Re: We are still early with the cloud

#175
post #153
post #150

Earlier quoted context omitted.

Well, arm and mips exist, are are no less capable than x86. And most apps don't really care which ISA they use. So that point is false. Now, what is that about alternate OS systems which can still do everything that Linux can, including handling network or service outages? (*well, there are BSDs, but I don't think thats what you had in mind)

My point is that the instruction set of these large CPUs (not AVRs etc) is itself just an abstraction to an inscrutable micromachine. That abstraction lets you develop a complex program without knowing the details. Unix was specifically designed for small, resource starved machines and did not have the powerful abstractions of mainframe OSes like Multics or OS/360. It's OK, but as modern CPUs and IO systems have grow…

As I said in the other comment, maybe people though that "cloud computing" is a different paradigm back in the 70's but it turns out that no, it's all the same distributed stuff.

If you have two processes on same machine, locking a shared data structure takes microseconds. You can easily update hundreds of shared maps and still provide great performance to user.

If you have datacenters in NY and Frankfurt, the ping is 90mS and fundamental speed of light limit say it will never be below 40mS.

So "lock a shared data structure" is completely out of the question, you need a different consistency model, remote-aware algorithms, local caches, and so on.

There are people who are continuously trying to replace Unix with completely new paradigms, like Unison [0].. but it is not really catching up, and I don't think it ever will. Physics is tough.

[0] https://news.ycombinator.com/item?id=27652677

Re: We are still early with the cloud

#176
post #97

Earlier quoted context omitted.

> you could easily imagine some Python-esque shell language (xonsh?) and have that be: > print(os.path.exists("ssh://user@rsync.net:fileThatExists")) That's just invoking the whole jungle when all you want is a banana.

What do you think happens when you invoke a shell? It's not some magical primitive, it also does string parsing and all the other stuff that a scripting language requires. SSH also has to parse the line! I did say Python-esque (I do get that Python in particular has a lot of stuff in its prelude). Really if you want to be super pedantic then the most "banana"-y isn't a line in your shell but some C library calls on b…

> What do you think happens when you invoke a shell?

It doesn't crash because I forgot to import os ?

Re: We are still early with the cloud

#177
post #16

> I'm excited for a world where a normal software developer doesn't need to know about... I'm not excited for this. There's a quote I cannot find that I miss greatly, but maybe a Whitehead quote or some such about Civilization being measured by that which it doesn't have to think about, that which it takes for granted. It's always struck me as powerful, but giving ourselves the ability to forget & un-learn does not t…

> Cap'n'Proto dared to dream a little more multi-service, to follow somewhat after E-language, but never materialized 3-plus-way communication. I still intend to implement this! It just has yet to become the most pressing issue for the projects I'm focused on, since the development model is already supported using proxying which makes 3-party handoff merely an optimization.

Its not at all like I dont see you being extremely extremely visible elsewhere doing tons of stuff. But I am excited to hear you still are excited for 3-party.

I'm not sure what thr designspace of a language that natively supports cap'n'proto would be & whether that'd be signififantly different than really good libraries or macros for a language. Maybe existing languages are flexible enough. But my gut is that we can mind of start having more ambient systems, ambient data, ambient code, more freely if we really built the language to work beyond the process scope from the start, using cap'n'proto as a base. I readily admit though there's probably some very fine ways to make this remote coding very seamless a development experience with what we've got though, if we want, perhaps with very very few rough spots.

Anyhow... thanks for the ongoing great work kv.

Re: We are still early with the cloud

#178
post #3

I can't think about the cloud without immediately grasping its huge downsides: absolutely no privacy at all, data lock-in, forced migration, forced obsolescence, and things just vanishing if the rent is not continuously paid. I have files on my computer from the 1990s and 2000s. If we lived in the cloud-centric world those projects that I did back then would probably be gone forever since I'm not sure I would have ke…

I used to agree about paying rent for my old files until I realized that it costs me anyways to ensure those files are available over a long time.

Re: We are still early with the cloud

#179

Earlier quoted context omitted.

> Educate me. Not sure if I'm being trolled... It finds a remote machine by name, and routes a connection to it. It authenticates and establishes a secure connection with the machine. It sends a command to the remote machine, the remote machine executes it, and the result is returned. It then puts the result into a form that can be used programmatically by the local shell. > That was a quick response to what I though…

I'm being trolled by someone who finds a DNS lookup and an encrypted TCP connection to send a textual command to another machine is somehow impressive, rather than entirely basic and, again, unimpressive. It then puts the result into a form that can be used programmatically by the local shell. That does sound better than returns one octet with two well-defined values , sure. And already the expert. Impressive. I know…

You seem quite unhinged for a self-proclaimed expert. Maybe it's time for a break from the internet.

Re: We are still early with the cloud

#180
post #151

Earlier quoted context omitted.

Poor analogy. You're welcome to address what I wrote directly if you'd like though.

It's quite an appropriate analogy. We used to write a lot of code in assembly code. I used to write microcode and even modified a CPU. But it's been decades since I last wrote microcode (much less modified an already installed CPU!) and now the instruction sets of MPUs like x86 and ARM are mostly just abstractions over a micromachine that few people think about. And an OS it the same: it used to be quite common to wr…

It's not an appropriate analogy because most people don't program in x86, but most people know (or can easily look up, when the need arises) basic Linux administration commands.
Post reply on HN