Show HN: Oya – New projects set up lightning fast | Hacker News Reader

Show HN: Oya – New projects set up lightning fast

oya.sh

116 pointsgo_bart106 comments

There’s too much obfuscation of what this software does. “New projects set up lightning fast” makes me think this is a generator framework like https://yeoman.io/ but the examples show an abstraction around bash snippets for running tasks.

It does seem to do both things but only after a bit of digging; and it’s still not clear what kind of experience I’ll have using packs.

To make the homepage compelling, I suggest;

1. Remove the illustrations, double-headings (like “Example usage/How to use...”), hero stuff, testimonials from your team. These are distracting

2. Start with the features, not `curl | bash`. I’ll download after I’ve decided I need these features.

3. Number the core features and list them in order of importance. Show (gif or terminal session text) how each feature works. I think you should cover:

- task runner feature

- templating feature

- scaffolding feature

- dependencies/modules/reuse between repos.

4. Move tutorial to page 2 so the features take center stage.

5. Drain away talk of ecosystem. You are just starting out with this. There is no ecosystem yet, so it is not a feature. Instead, specifically talk about the add-ons you already built, and how they can help me.

Fantastic suggestions! Thank you so much for taking the time! We'll definitely going to take them into account and revise the home page. Good stuff!

Yeoman was my first thought as well when I've scroll through that website :)

> There’s too much obfuscation of what this software does. “New projects set up lightning fast” makes me think this is a generator framework like https://yeoman.io/

Wow, how did you guess that it was even in the ballpark of yeoman?

> New projects set up lightning fast ... Oya with its ecosystem of powerful, reusable packs lets you bootstrap deployable projects without a hassle.

AFAICT this could describe work in virtually any programming domain. Who doesn't create new projects or need them to be deployable?

For good examples (IMHO) of the above consult https://zeit.co/now

I went through most of the documentation but I still don't understand how this will help me in any way. I don't understand what it is?

> Become a hero

Marketing jargon like this is IMO very tiring. I am a hero because I use your product? Ok, I guess that is a very loose definition of that word.

I don't want to be negative really, but I have actually no clue what this product does or what problem it solves.

You're not being negative, that's super useful feedback. We're using Oya internally but are still struggling with making it 100% (or even 80%:) clear what it is that it does. :)

It's best balanced with the feedback of people that have the opposite opinion. I don't think there's anything wrong with it. Being a hero is ingrained into our culture, and I think comic book culture is a net win for society, but if you hate comic books and seeing the term hero bandied about, that's fine. To each their own. But I will never be annoyed by it.

Thank you.

Perhaps I'm not your target audience which is just fine. But I would suggest to make some example of real world issues that Oya solves.

Right now it just felt way too generic and the silly marketing is not really helping. It could help to explain who will view you as a hero when using your product instead of just being a hero in the general sense, which is clearly not the case.

Honestly there's been so many "save time and spend it writing code that matters" tools hitting the HN front page in the past year that I've just tuned them out.

I have to agree here. Out of all the things I've seen, the hero part was the only one that made me cringe.

Other than that, I couldn't figure out much of what this product can offer me. For a while I thought it was yet another NodeJS kind of framework for bootstrapping the millions of other frameworks there.

This is really just a Makefile in yaml without lots of the features and the milions of support articles.

It feels like a header called “why this is better than GNU Make” should be somewhere in there. With the provided example, it looks like Oya does less than POSIX Make (which is significantly less powerful than either BSD or GNU Make).

They do mention this in their documentation now, but don’t offer any concrete examples of where it can even compete with Make.

> If you’re familiar with Makefiles, you may have noticed some similarity here. The main difference is because we’re using standard YAML files, is the pipe character after task name. An added bonus you don’t have to use tabs. :>

> If all Oya offered was poor-man’s Makefiles, you’d better find something better to do. Fortunately, Oya has much more to offer so keep reading.

The password encryption functionality looks useful but you could probably just use SOPS in your Makefile.

I call into Make from my CircleCI config files just to avoid writing shell in a YAML file.

This is a very good point.

Ignoring that a Makefile makes more sense than a yaml file anyway (what the is a “standard yaml file”?), “you don’t have to use tabs” really shows how ridiculous things have gotten.

I can’t believe someone spent $35 on a domain for this much less however many man hours went into it.

I wouldn’t quite go that far (since it obviously has some value for the people who use it over Make, despite the fact that they are unable to communicate it effectively; at the very least it was a good learning experience for the authors), but you should see how much code did go into the project: https://github.com/tooploox/oya/tree/master/pkg

Looks like it's just just.

https://github.com/casey/just

> curl https://oya.sh/get | bash

You lost me right there. No checksum, no digital signature - if your server gets hacked, so do your customers.

Why don't you use your github releases in the installation instructions?

It's already on GitHub, the shell script is just a wrapper to handle automating the download and install of the latest release.

Running random automated scripts from the web is not a good idea

Like 95% of websites with JavaScript? :)

No, because JS runs in the browser sandbox and has no access to the rest of your machine. That's very different to running a bash script from curl.

It's not meaningfully different than downloading software with an installer/install script and running it on your machine. Though obviously, you could just curl it, read it, and then bash it.

If their GitHub account gets hacked, so do their customers. What's the fundamental difference?

You have the download at github and the checksum at you webserver. Same effort, but now attackers would have to have both services compromised to plant a malicious download.

So you refuse to download and install any executable unless it's served over https from one source and matches a checksum listed on a different source?

And the argument here is that if you don't do that, you're shit at security?

No, I've said "Same effort, but now attackers would have to have both services compromised to plant a malicious download"

Since it's HTTPS, a signature or checksum are pretty pointless, TLS will do the certificate checking and encryption for you.

Your assertion that "if your server gets hacked, so do your customers", also applies to a checksum, as the hackers would just change the checksum listed on the website.

If you have a problem with piping curl to bash, then you can just not do so, you can download the bash script, see what it does, and modify it before running it. It's only 140 lines and it's fairly simple.

Further to your point, the bash script also does checksums internally!

Putting releases up on github isn't a bad idea, but their github account credentials could also be hacked, so it's no more secure than this really.

I don't understand your first paragraph. Could you elaborate?

curl will error out if the chain of trust is invalid, unless you override it with the -k option.

Guess what, all you need to prove in order to get a new "valid" cert is that you control the server. And, if you control the server then you already have access to the original certificates, so you probably don't even need new certs.

Since it's HTTPS, a signature or checksum are pretty pointless, TLS will do the certificate checking and encryption for you.

Serving the file over HTTPS is good because it means no one can do a man in the middle attack to change it, but it's not enough to be secure. If someone compromises the server itself the file could be altered at the source. The point of the checksum is to ensure that the file you're downloading is the file you're expecting. If you host the file in one place and the website in a different place it's harder for an attacker to change both the file and the website that reports the checksum, so you can be much more confident the file is correct. HTTPS on it's own doesn't give you that.

> If you host the file in one place and the website in a different place it's harder for an attacker to change both the file and the website that reports the checksum, ...

That is not a practical solution at all. What do users find if they enter the "download" page? A link to an external site containing the checksum? Wouldn't an attacker just replace (or remove!) the link?

The reality of today's identity management is TLS and certificates. If your website is https://oya.sh, then obviously any attacker who has access to the web server can direct clients to their malware downloads. No extra servers will help against that.

Perhaps not practical, but I could see this as one actually useful example of how a blockchain-style distributed ledger could be used. Have two accounts, one posts the binaries, another posts the checksums. That way one account breach doesn't compromise the whole thing, and the ledger could prove the history, etc.

Agreed. There could be better solutions than the current reliance on X.509 certificates and TLS, for example a blockchain solution like you propose.

But the fact that these solutions do not exist or at least aren't commonplace, makes the criticism to Oya in this regard rather awkward. They are doing what everybody does for their downloads: Relying on the certificate chain.

A link to an external site containing the checksum? Wouldn't an attacker just replace (or remove!) the link?

It wouldn't need to be an external site. You can have more than one server running a domain, with a different set of keys (entirely different architecture if you want) to make hacking both harder.

I still don't really see how this makes hacking harder. An attacker needs to replace the information presented to the user in order to download the software. For instance, the "download" link, or the paragraph describing the download/checksum procedure.

This always originates from one spot for one user. You can spread among users, but you can not spread a single html snippet over machines in a way that a hacker couldn't replace the "root" html snippet.

If someone compromises the server itself there's basically no form of security from that point that would help. The attacker could just put anything on the downloads page, including a new checksum for the compromised download. Nothing is safe if the server falls into malicious hands, but TLS is much easier for both the user and the website host when compared to a checksum, so that's probably the best decision for this kind of system.

The only time where I'd recommend a checksum over TLS is when you're dealing with a very large download, like a Linux ISO or something. The TLS encryption would cause a noticeable slowdown, so in that case a checksum may provide the best user experience.

A blog on this general attitude: https://sandstorm.io/news/2015-09-24-is-curl-bash-insecure-p...

The difference between a digital signature and HTTPS for identity verification is probably somewhat of a toss-up, and a checksum hosted on the same server as the download is mostly useless for anything but ensuring your download of the malicious version completed successfully.

Thanks, good read. :)

I recall two other popular projects doing the curl xyz| bash approach

Rust[0] Chef [1]

And here is an old HN comment[2] going into why it doesn't really matter.

Besides it's a Show HN- why be negative when we can raise the same issue more constructively as "Please add checksums and digital signatures. Also why not use regular GitHub releases in the installation instructions?"

[0] https://doc.rust-lang.org/book/ch01-01-installation.html [1] https://docs.chef.io/install_omnibus.html [2] https://news.ycombinator.com/item?id=12766049

RVM requires GPG keys which is the way to do it properly: https://rvm.io/

Exactly. A hash to verify the authenticity of the file / binary itself is what’s missing. Https is not enough.

Brew

Security concerns aside, a misconfigured gateway in between (say, they use Cloudflare) can easily result in an “HTML” response being piped to my bash. The f-ing mess it could create in my home directory is unimaginable.

Really. I didnt know that was realistically possible. Do you have an example payload to create such a mess?

A docker image would be much better than a random script.

Why? Then you have to run the whole thing in Docker. That's a wholly unnecessary extra dependency.

Besides, this modality of installation already has precedent with Brew and Rust.

I'm talking about the cryptographically verified part. Either you are using a package manager to manage versions, roll back, lock versions,etc.

Or you use docker.

Not entirely sure if a standalone script with no versioning is the best way to do this in day and age.

I really recommend pipethis [1] for these scenarios. It's based on public-key cryptography, so an attacker who gains control of the server can't just update the hash (hosted on the same server).

[1] https://github.com/ellotheth/pipethis

I would say: It is better to have no "testomonial" at all than to quote yourself.

"My mom says I'm handsome"

It this case, this is more like a foster parent; Oya started as a part-time open source project, then Tooploox sponsored further development after having used it internally.

How does this add anything to my process compared to npm tasks, that do the automated work right now, together with out Gitlab CI system?

It isn't restricted to JavaScript/Node, for one.

Not everybody uses JavaScript. There are many language-specific task runners (e.g. Rake, Mage etc.). Oya is aiming to be language agnostic and lightweight (not require a ton of dependencies).

Fair point, thanks for pointing it out.

This is a horrible marketing piece...I'm assuming it bootstraps a go project because one of the files was go, but nowhere does it say what language/framework you're bootstrapping...at first I assumed it was just another express.js bootstrapper...

It's language-agnostic. But point taken, thank you!

Thanks for being honest. Can you tell more what we could do better with Oya and, be length, with other Open Source initiatives?

Let it be known, I'm bitching with love, I appreciate the work done, and wouldn't be bitching if I didn't... <3

I'm so confused by the frontpage of this, it looks like an alternative to Make with _no reason_ why I should use it over make. Seriously, there's not one feature on the homepage that isn't more obviously done with Make... Probably should pull that credentials example outta the docs and onto the homepage. And... on the homepage, please, please tell me:

what problems does this tool solve?

... Why was it created? Because generating new apps is like an "almost never" problem for me. Not to say it's not "un-fun" sometimes, but in reality, it's like the smallest amount of time I'll spend in the entirety of a project.

If anything the fact it's not Make, or whatever is canonical for the language/runtime, seems like a disadvantage because it's one more abstraction I'll eventually have to use... unless there are some wicked sweet problems it solves.

Also, the fact the user configuration language is `go` also seems like a disadvantage. As much as I hate to say it, JavaScript would probably be a better choice if you need users to have access to a language for scripting tasks (I know nothing about go but a quick google gave me this: https://github.com/jingweno/godzilla). Does it already support multiple languages? Examples of that would be awesome too.

One love. Hope my comments are constructive for y'all.

Seems like Yeoman? https://yeoman.io/

Scaffolding is just a part of what Oya. The purpose is not just creating new projects but also making managing them easier with focus on devops.

You can: 1. Create bash-based tasks similar to what Makefiles do.

2. You can parametrize these tasks AND templates using YAML files such as values.oya (they can be encrypted).

3. You can share/reuse your scripts by just pushing them to Github and tagging using a version and then import them into your Oyafile (`oya import github.com/bilus/mypack`)

IMHO using Ansible to configure new projects is probably a more robust solution than using something like this. Although Ansible is generally focused on CM solutions for dev/testing/prod environments there is no reason why you couldn't use it for developer workstations as well. There are obviously way more Ansible plugins and examples online and it has far more capabilities than this product. I don't understand what this is really going to buy me over something like that. The only thing I can possibly see is the whole pack concept for a development project, but I honestly think something like that could be built on top of Ansible as a base and be far more powerful.

It's really frustrating to read about a sw product and not understand what it does. idk if I'm dumb, or it's a generation gap. Is this oya thing so complex it cannot be described in a way a fellow developer could understand?

I get this impression with quite a few software project websites. They sometimes seem to assume that anyone who visits their website has experience in a specific area. I mean nothing against going for your target audience, but in some cases it's hard to tell if I just don't get it or if it's something that doesn't concern me anyway.

I don’t like to go meta, but this is the meanest response to a Show HN I’ve seen in a while. Almost every comment is a reason why it sucks or a random nitpick.

If you don’t have anything nice to say, just don’t say anything at all.

This comment makes no sense. Show HN is supposed to gather feedback, not "likes".

If you don't want honest feedback, then why bother posting here? I find people take honest criticism as personal attacks way too often. Nothing criticized here detracts from what they've done. If this was my product, I'd be super happy that I got this huge list of things to improve out of a single post.

Compare that to a few "weeeeee, it's nice!" comments.

If you want empty happy feedback, share it on Facebook.

It's just really bad marketing. We aren't a cheer team, this is honest feedback and discussion.

The feedback allows companies to better their product.

Well... they asked for feedback. But I do find many, many people on HN are far ruder than they would be to a friend presenting the same thing, which distresses me.

OTOH I expect anything I submit to HN to get treated with the same kind of brutality, but what I get in return is the attention of some of the smartest people on the Net. It’s a painful trade off but it does help you to expect hurt feelings going in.

If I had a project to Show HN and got this much feedback, I would actually be totally stoked. When feedback is mostly positive, you can't tell if people are sugar-coating or flat out lying to you. This stuff is largely very constructive. The main points are:

- No one really knows what this is, or what problem it solves

- If it's a Make replacement, why not just use Make?

- Is this a new syntax or just YML?

- The marketing approach seems to miss the mark

With that alone they can refine their presentation and message quite a bit. That's quality and honest feedback, even though it might not feel good at first.

The product website links on the footer are not functional. I advise to hide them until you have the pages up.

Great point, thanks!

That fading animation on the homepage is super terrible.

Agreed, I fail to understand the popularity of this aesthetic, but it is rather common on 'landing pages' for potentially interesting coding projects. It usually just makes the bottom half of my screen unused real estate.

Yeah, I thought I was having vision problems because I couldn't read anything above or below the midpoint of my monitor.

I'm an early adopter for new shiny things, but this is dead on arrival for me. You made no effort to tell us what Oya actually is. It's as if you wrote this website for yourselves, not for the general public.

A few pointers:

- What is a "project"?

- Is Oya a language?

- What is this new Oyafile syntax?

- What actual problem is this solving?

My company definitely has a use-case for something like this. We are currently working on an internal product to easily set up new projects, whether they are java, ruby, lambdas, etc. We are using/abusing yeoman to do this, but yeoman was not intended to be used in a pipeline initialized from a web ui. A second issue we have is a blossoming of scripts. Some have multiple bash scripts. Some have started using makefiles.

This seems to be exactly what we could be using but I don't see a clear explanation of how it provides the initial value over something like Yeoman, and how it provides the lasting value over things like bash scripts or makefiles.

This seems like a good idea but I get the feeling its been done (npm, pip, makefiles, gist, etc..) or tried to be done a lot of times and I'm not sure what makes this different. But maybe I'm just a laymen and don't understand the finer points so if there's a compelling argument my feedback is to include something about it on the homepage or in a FAQ.

I think this is the key question we should address right there on the home page. Thank you for this.

What if we could have examples on our homepage that actually made the product seem useful in some way...

That’s like 99% of software these days. So frustrating.

Thanks, I appreciate the honest feedback! We'll try better.

This feedback is SO FREAKING valuable...

Could really use this kind of evaluation of our new platform.

https://news.ycombinator.com/item?id=19964067

Is there a reason as to why you didn't title it "Show HN: Koji - An app templating service" and link to the site directly ? I'd argue that you would get a larger response that way.

Couldn't agree more!

So it's a replacement for `make` with some fanciness thrown in?

Seems okay. Not sure I'd use it, but the model is proven. If it's a true improvement, it'd be nice.

Another one to the list...

https://news.ycombinator.com/item?id=12766049

Quoting a testimonial on the website by the co-founder of Tooploox is not really a thing, right?

Tooploox is the creator of Oya.

It was created as an independent open source project, then used internally @ Tooploox, then development got sponsored by Tooploox so it does make sense from our (very subjective) pov.

But I agree AFTER it got moved to Tooploox Github it looks kinda self-serving.

Thanks for the history lesson, but that history is missing from your website. Others may have the same thinking as I have without the history lesson.

I would take it out. It seems a bit silly :)

I like this and I see the need for it, being a long time Make user and supporter. Will give this a try.

What uses are you seeing for it that the rest of us aren’t? I’m genuinely interested because their marketing makes it super challenging to see what the product is useful for.

Standard way of sharing project templates (scaffolding). Might be useful on systems based on micro services and serverless. I don’t see much value in the task runner part of it, though.

Just a heads up : Tooploox, Packs and Documentation are the only working links in your footer.

Is this a make reimplementation

I guess, with a oneline description like that, I expected a project minter like cookiecutter or dzil new (or yeoman), but the more I read, the more this looks like make without the dependency resolver

No. But it's a very valuable question; it shows we clearly have a problem with making it clear.

Looks funky... but what problem does it solve?

Seems like make?

Just use docker.

Reply on news.ycombinator.com