Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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


you could easily imagine some Python-esque shell language (xonsh?) and have that be:

print(os.path.exists("ssh://user@rsync.net:fileThatExists"))

A boolean, a still (relatively) terse line of code. And when you end up wanting to do something even a bit more complicated it'll be a smooth gradient of difficulty.

As with every discussion around shells, though, the amazing terseness of scripts is great, but every form of programmatic behavior beyond "do this then that" and "do string interpolation here" is a massive pain in the butt. The biggest advantage is that stuff like pipes are a very good DSL.


> 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 both sides of the system.


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

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


btw, assuming you're deploying on kubernetes:

you're omitting the 500 lines of yaml needed to deploy that, the tens of megabyte for the python base image (of which you'll waste more than 99.99%) and the tens of megabytes in bandwidth to the docker registry and to download it on the kubernetes worker... And the image wight should be accounted at least four times: worker node + 3 in the docker registry (ha and stuff).

it's incredibly inefficient if you just freaking want to know if a file exists.


Am I understanding correctly that the concern is syntax based? If so, why not build a wrapper over the existing shell language? If not, can you please clarify?


Well my first thing is I would want a defacto norm adopted in the same way that bash is basically available everywhere. And of course we would want it to be something that doesn't have the busted dependency story of Python. And I would like for third party programs to have a rich interface be provided through this new shell.

For example, you can interact with docker in Python with a lib, but it would be amazing if the docker binary just exposed an RPC interface and API for script languages so you wouldn't have to parse out things from output or otherwise try to figure things out when writing shell scripts. This is, of course, the PowerShell thing, but PS's aesthetics displease me and many other people.

Computers are, of course, turing complete. You can do whatevery you want, really. But for example I end up using zsh instead of xonsh because I want to use what other people write as well.


Understandable, the challenge is beating the xkcd one more universal standard.


    # 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.


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?


Lambda has been a thing since 2014 and more and more of it are “serverless” as the years go by.

EC2 was a necessary step and though and even that bought things like per second billing, autoscaling and infrastructure as code to the masses.


Well AWS has been quite clever, using both Xen originally and also now KVM VMs, but everything else is based on that yeah. But that's gotten really complex over the years. They now use a container execution environment called firecracker or something that is open sourced and might be totally separate from their virtualized environment - or at least on top of it where they do let you just run little jams. Cloud isn't bad, I just mean you do have to transfer octets somehow from exec to exec. There are more and less efficient ways of doing it, and also more and less secure ways too - and abstract ways. Not all bad.


Think the point is that as I am writing software, I don’t care about any of that. I expected an opinionated environment when I first heard the word cloud 2 or so decades ago; I wanted to put my code in cvs (git now) and that’s it; I don’t want to think of anything outside that. Especially security or scaling.

I ran 1000s of physical Linux servers over the decades using chroots when it was not fashionable to have containers yet with db clusters because I don’t want my laptop to be different than my servers and I don’t want to think or worry about scaling.

We have aws Lambda now, but it is too expensive and, for me, not trivial enough. It actually requires too much thinking (architecting) to make something complex with it and a lot of that is about money; you can stumble into bills that require at least a kidney to settle.

So I still run my own servers, these days with openfaas. With many scripts, it is almost painless and costs almost nothing (we provide for millions of users for a less than 200$ a month in total). But it still is not the dream: I still cannot just forget about everything hosting and abstractions still leak enough but at least I don’t spend more than a few hours a year on it and I don’t go bankrupt like can happen with Lambda.

We are building our own language and runtime (lisp like with types) to fix this: after 40 years of programming, I am pretty much fed up with having computing power and loving programming but having to deal with all this pointless (for programmers!) stuff around it: we went backwards, at least somewhat.


Interesting to hear people who use OpenFaas. Seems you are happy with it? Any big problems?


I like it for many reasons, but especially the helpful community, founder and everything just works. We use it with Istio at the moment. We switched from Cockroach (did not like the license and we had a few perf issues) to Yugabyte en Scylla recently for micro service and Monolith scaling to use with openfaas and it is really scaling to anything we need. Of course different situations have different needs, but this works very well for us.


[flagged]


Personal attacks; that’s not very common here. However, enlighten me to this perceived misunderstanding?


well, when I first saw a aws prompt in 2006 or so, I was relief that EC2 was a plain debian-like machine.

Also I was saving me a phone call with Dell and a sunday evening configuring some hardware.

No new bullshit paradigm to learn, I could shove my code in there with tool I knew and call it a day.

EC2 was a stepping stone and it worked well to get some stuff in the cloud.

Remember the early days when only non-critical, non-PII stuff were in the cloud? And how some companies "just can't use it because of X" ( or worse the dreaded Y )


Little functions in the void suck, because the void is crazy complicated and has all kinds of things you have to think about


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?


I didn't write to explain what an abstraction is, and I will assume you honestly meant to congratulate me instead of trying to be sarcastic. Thank you for that.

I have had two types of developers in my teams: one type that understands the underlying technology of the abstractions that they are using, and one type that only understands the layer/abstraction they are interacting with and blissfully clueless about anything underneath.

Neither group worries about transistors or proton decay in their hardware, and both can make 'things'. However, one group is much more capable of effectively building tools and understanding issues when something goes wrong in the chain, whereas the other group is regularly hopelessly lost because they have no clue of what is happening. I'll let you guess which is which.

This is not about worrying or even being bothered with details, but about understanding what you're working with.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: