-
Looks like So You Start is just reselling OVH servers. Why not just go straight to OVH?
-
So You Start is an OVH company, it’s their cheaper server line.
-
-
We’re considering introducing this in at work, because apparently maintaining docs and client libs is too difficult for today’s engineers. Am curious what other lobsters have had as experiences.
-
My experiences have been pretty positive. At the very least, it’s way better than what most organizations use instead (i.e. nothing).
My first time using it, I was grafting it onto an existing API and was pleasantly surprised to see that it was expressive enough to bend to the existing functionality. All the stuff it enables is great – automated conformance testing being the big one, in my book.
-
Ah, neat. I already had been running boring documentation and updates (wiki ops, wheee), and am resistant to change if something works.
But, if it’s been working well for other folks, it’s worth investigating.
-
maintaining docs and client libs
Have you thought about gRPC, or twirp at all? If the use-case is internal-facing systems then I think what a lot of people really want is RPC. Swagger seems great for external-facing systems, though.
(Disclaimer: I haven’t used any of the tools I just mentioned :D)
-
-
-
We have also used it quite a bit at work, getting the most benefit from automatic documentation of endpoints. The automatic client lib generation didn’t work very well for us, and hand written clients were our approach.
Depending on what your API is written in, you may have quite good support for generating pretty detailed docs.
Also, this opens the door for some kind of automated testing against the API, based on the Swagger definition, but, I never got around to doing that.
-
We use https://www.apibuilder.io/
-
-
I’ll be working on securing some Ubuntu Linux servers. At this point I’m mostly thinking IP tables. Any suggestions in that area would immensely appreciated.
I’ll also be looking into the best way to add formatted text my pet project using GTK and Vala. Right now I’m just writing out to a textbox and frankly it’s hideous and unreadable. I need a better way really bad.
-
i’ve always ran http://www.fail2ban.org/wiki/index.php/Main_Page + some aggressive firewall rules
-
-
I recommend using ferm instead of messing with iptables rules directly. It makes some great abstractions and it’s a lot cleaner to read imho.
As others have said, run fail2ban on any public facing services. rkhunter and Monit can also be helpful.
Make sure you also subscribe to ubuntu-security-announce so you stay up to date with any security releases.
-
-
-
-
The valadoc website was mainly designed by the folks at elementary OS and yes the person from vala-lang is also involved with the project. If you want to give some feedback on the website, you can dropinto #elementary on freenode, it’s bridged to the slack where everyone hangouts. You can also send me a message and i’ll relay it there (i am a contributor to elementary OS)
-
-
-
-
-
-
If your UI isn’t terribly complicated and portability isn’t an issue, then honestly the best way is to toss GTK in the trash.
I maintain a MUD client which I initially wrote against GTK. I ran into the same problem as you, got annoyed, and rewrote it to directly call X11 functions. The new code is shorter and it’s not a gigantic pain in the ass to go off-piste.
-
I maintain a MUD client which I initially wrote against GTK. I ran into the same problem as you, got annoyed, and rewrote it to directly call X11 functions. The new code is shorter and it’s not a gigantic pain in the ass to go off-piste.
Calling X11 directly is cleaner than an actual GUI toolkit? Or even Athena vs. any modern toolkit? Most people I’ve seen would have switched to Qt, but I’ve never seen anyone call X11. How is portability?
-
For what it’s worth, my UI looks like this.
How is portability?
It runs on at least two different Linux distributions :)
-
-
I don’t think anyone has brought it up for a few years, but you can still pay cash for ingame items, so I guess that counts. :<
-
-
-
-
No, at this point, the UI isn’t that bad. I’ve seen a lot worse.
I’m not wedded to GTK in any other way except the rest of the program is written in Vala.
I’ve thought about just embedding a web browser and going that route. I think I can do WebKit without a lot of work. My only hesitation there is that I’ll have to do web design and I’m terrible at that.
-
Is your project open source? I’d be open to helping you with the design part. ;)
-
-
-
-
-
Git via email sounds like hell to me. I’ve tried to find some articles that evangelize the practice of doing software development tasks through email, but to no avail. What is the allure of approaches like this? What does it add to just using
gitby itself?I tried to collect the pros and cons in this article: https://begriffs.com/posts/2018-06-05-mailing-list-vs-github.html
I also spoke about this at length in a previous article:
https://drewdevault.com/2018/07/02/Email-driven-git.html
While my general experience with git email is bad (it’s annoying to set up, especially in older versions and I don’t like it’s interface too much), my experience of interaction with projects that do this was generally good. You send a patch, you get review, you send a new, self-contained patch, attached to the same thread… etc, in parallel to the rest of the project discussion. It’s a different flavour, but with a project that is used to the flow, it can really be quite pleasing.
I think the selling point is precisely that it doesn’t add anything else. Creating a PR involves more steps and context changes than git-format-patch git-send-mail.
I have little experience using the mailing list flow, but when I had to do so (because the project required it) I found it very easy to use and better for code reviews.
I’m not sure I understand. What steps are removed that would otherwise be required?
Simply, it’s “create a fork and push your changes to it”. But also consider that it’s…
In this workflow, you switched between your terminal, browser, mail client, browser, terminal, and browser before the pull request was sent.
With git send-email, it’s literally just
git send-email HEAD^to send the last commit, then you’re prompted for an email address, which you can obtain from git blame or the mailing list mentioned in the README. You can skip the second step next time by doinggit config sendemail.to someone@example.org. Bonus: no proprietary software involved in the send-email workflow.Also github pull requests involve more git machinery than is necessary. Most people, when they open a PR, choose to make a feature branch in their fork from which to send the PR, rather than sending from master. The PR exposes the sender’s local branching choices unnecessarily. Then, for each PR, github creates more refs on the remote, so you end up having lots stuff laying around (try running
git ls-remote | grep pull).Compare that with the idea that if you want to send a code change, just mail the project a description (diff) of the change. We all must be slightly brainwashed when that doesn’t seem like the most obvious thing to do.
In fact the sender wouldn’t even have to use git at all, they could download a recent code tarball (no need to clone the whole project history), make changes and run the diff command… Might not be a great way to do things for ongoing contributions, but works for a quick fix.
Of course opening the PR is just the start of the future stymied github interactions.
In my case I tend to also perform steps:
man git-remoteto see how to point my local clone (with the changes) to my GitHub forkgit remotecommandsman git-pushto see how to send my changes to the fork rather than the original repoTo send email, you also have to have an email address. If we are doing a fair comparison, that should be noted as well. Granted, it is much more likely that someone has an email address than a GitHub account, but the wonderful thing about both is that you only have to set them up once. So for this reason, it would be a bit more fair if the list above started from step four.
Now, if I have GitHub integration in my IDE (which is not an unreasonable thing to assume), then I do not need to leave the IDE at all, and I can fork, push, and open a PR (case in point, Emacs and Magithub can do this). I can also do all of this on GitHub, never leaving my browser. I don’t have to figure out where to send an email, because it automatically sends the PR to the repo I forked from. I don’t even need to open a shell and deal with the commandline. I can do everything with shortcuts and a little bit of mousing around, in both the IDE and the browser case.
Even as someone who is familiar with the commandline, and is sufficiently savvy with e-mail (at one point I was subscribed to debian-bugs-dist AND LKML, among other things, and had no problem filtering out the few bits I needed), I’d rather work without having to send patches, using Magit + magithub instead. It’s better integrated, hides uninteresting details from me, so I can get done with my work faster. It works out of the box.
git send-emaildoes not, it requires a whole lot of set up per repo.Furthermore, with e-mail, you have to handle replies, have a firm grip on your inbox. That’s an art on its own. No such issue with GitHub.
With this in mind, the remaining benefit of
git send-emailis that it does not involve a proprietary platform. For a whole lot of people, that’s not an interesting property.I did note this:
Only if you have a GitHub account and authorize it. Which is a similar amount of setup, if not more, compared to setting up git send-email with your SMTP info.
You only have to put your SMTP creds in once. Then all you have to do per-repo is decide where to send the email to. How is this more work than making a GitHub fork? All of this works without installing extra software to boot.
With GitHub, I do not need to obtain any email address, or dig it out of a README. It sets things up automatically for me so I can just open a PR, and have everything filled out.
Lets compare:
e-mail:
magithub:
The first two steps are pretty much the same, both are easily assisted by my IDE. The difference starts from step 3, because my IDE can’t figure out for me where to send the email. That’s a manual step. I can create a helper that makes it easier for me to do step 4 once I have the address, but that’s about it. For the magithub case, step 3 is
SPC g h f; step 4SPC g s p u RET; step 5SPC g h p, then edit the cover letter, and, c(orC-c) to finish it up and send it. You can use whatever shortcuts you set up, these are mine. Nothing to figure out manually, all automated. All I have to do is invoke a shortcut, edit the cover letter (the PR’s body), and I’m done.I can even automate the clone + fork part, and combine push changes + open PR, so it becomes:
Can’t do such automation with e-mailed patches.
I’m not counting GitHub account authorization, because that’s about the same complexity as configuring auth for my SMTP, and both have to be done only once. I’m also not counting registering a GitHub account, because that only needs to be done once, and you can use it forever, for any GitHub-hosted repo, and takes about a minute, a miniscule amount compared to doing actual development.
Again, the main difference is that for the e-mail workflow, I have to figure out the e-mail address, a process that’s longer than forking the repo and pushing my changes, and a process that can’t be automated to the point of requiring a single shortcut.
Creating a GitHub fork is literally one shortcut, or one click in the browser. If you can’t see how that is considerably easier than digging out email addresses from free-form text, then I have nothing more to say.
And we haven’t talked about receiving comments on the email yet, or accepting patches. Oh boy.
You already had to read the README to figure out how to compile it, and check if there was a style guide, and review guidelines for contribution…
Note that your magithub process is the same number of steps but none of them have “so I won’t have to figure it out ever again”, which on the email process actually eliminates two of your steps.
Your magithub workflow looks much more complicated, and you could use keybindings to plug into send-email as well.
You can do this and even more!
I might have read the README, or skimmed it. But not to figure out how to compile - most languages have a reasonably standardised way of doing things. If a particular project does not follow that, I will most likely just stop caring unless I really, really need to compile it for one reason or another. For style, I hope they have tooling to enforce it, or at least check it, so I don’t have to read long documents and keep it in my head. I have more important things to store there than things that should be automated.
I would likely read the contributing guidelines, but I won’t memorize it, and I certainly won’t try to remember an e-mail address. I might remember where to find it, but it will still be a manual process. Not a terribly long process, but noticeably longer than not having to do it at all.
Because there’s nothing for me to figure out at all, ever (apart from what repo to clone & fork, but that’s a common step between the two workflows).
How is it more complicated? Clone, work, fork, push, open PR (or clone+fork, work, push+PR), of which all but “work” is heavily assisted. None of it requires me to look anything up, anywhere.
And I do, when I’m dealing with projects that use an e-mail workflow. It’s not about shortcuts, but what can be automated, what the IDE can do instead of requiring me to do it.
You can, if you can extract the address to send patches to automatically. You can build something that does that, but then the automation is tied to that platform, just like the PRs are tied to GitHub/GitLab/whatever.
And again, this is just about sending a patch/opening a PR. There’s so much more PRs provide than that. Some of that, you can do with e-mail. Most of it, you can build on top of e-mail. But once you build something on top of e-mail, you no longer have an e-mail workflow, you have a different platform with which you can interact via e-mail. Think issues, labels for them, reviews (with approvals, rejection, etc - all of which must be discoverable by programs reliably), new commits, rebases and whatnot… yeah, you can build all of this on top of e-mail, and provide a web UI or an API or tools or whatever to present the current state (or any prior state). But then you built a platform which requires special tooling to use to its full potential, and you’re not much better than GitHub. You might build free software, but then there’s GitLab, Gitea, Gogs and a whole lot of others which do many of these things already, and are almost as easy to use as GitHub.
I’ve worked with patches sent via e-mail quite a bit in the past. One can make it work, but it requires a lot of careful thought and setup to make it convenient. I’ll give a few examples!
With GitHub and the like, it is reasonably easy to have an overview of open pull requests, without subscribing to a mailing list, or browsing archives. An open PR list is much easier to glance at and have a rough idea than a mailing list. PRs can have labels to help in figuring out what part of the repo they touch, or what state they are in. They can have CI states attached. At a glance, you get a whole lot of information. With a mailing list, you don’t have that. You can build something on top of e-mail that gives you a similar overview, but then you are not using e-mail only, and will need special tooling to process the information further (eg, to limit open PRs to those that need a review, for example).
With GitHub and the like, you can subscribe to issues and pull requests, and you’ll get notifcations about those and those alone. With a mailing list, you rarely have that option, and must do filtering on your own, and hope that there’s a reasonable convention that allows you to do so reliably.
There’s a whole lot of other things that these tools provide over plain patches over email. Like I said before, most - if not all - of that can be built on top of e-mail, but to achieve the same level of convenience, you will end up with an API that isn’t e-mail. And then you have Yet Another Platform.
Because the work for the send-email approach is: clone, work, git send-email. This is fewer steps and is therefore less complicated. Not to mention that as projects become more decentralized as they move away from GItHub, the registration process doesn’t go away and starts recurring for every new forge or instance of a forge you work with.
Yes, that’s what I’m advocating for.
No, I’m proposing all of this can be done with a very similar UX on the web and be driven by email underneath.
So let’s add that to mailing list software. I explicitly acknoweldge the shortcomings of mail today and posit that we should invest in these areas rather than rebuilding from scratch without an email-based foundation. But none of the problems you bring up are problems that can’t be solved with email. They’re just problems which haven’t been solved with emails. Problems I am solving with emails. Read my article!
So what? Why is this even a little bit of a problem? What the hell?
You can’t subscribe to issues or pull requests, you have to subscribe to both, plus new releases. Mailing lists are more flexible in this respect. There are often separate thing-announce, thing-discuss (or thing-users), and thing-dev mailing lists which you can subscribe to separately depending on what you want to hear about.
No, you won’t. That’s simply not how this works.
Look, we’re just not on the same wavelength here. I’m not going to continue diving into this ditch of meaningless argument. You keep using whatever you’re comfortable with.
I just remembered a good illustration that might explain my stance a bit better. My wife, a garden engineer, was able to contribute to a few projects during Hacktoberfest (three years in a row now), with only a browser and GitHub for Windows at hand. She couldn’t have done it via e-mail, because the only way she can use her email is via her smart phone, or GMail’s web interface. She knows nothing else, and is not interested in learning anything else either, because these perfectly suit her needs. Yet, she was able to discover projects (by looking at what I contributed to, or have starred), search for TODOs or look at existing issues, fork a repo, write some documentation, and submit a PR. She could have done it all from a web browser, but I set up GitHub for Windows for her - in hindsight, I should have let her just use the browser. We’ll do that this year.
She doesn’t know how to use the command-line, has no desire, and no need to learn it. Her email handling is… something that makes me want to scream (no filters, no labels, no folders - one big, unorganized inbox), but it suits her, and as such, she has no desire to change it in any way.
She doesn’t know Emacs, or any IDE for that matter, and has no real need for them, either.
Yet, her contributions were well received, they were useful, and some are still in place today, unchanged. Why? Because GitHub made it easy for newcomers to contribute. They made it so that contributing does not require them to use anything else but GitHub. This is a pretty strong selling point for many people, that using GitHub (and similar solutions) does not affect any other tool or service they use. It’s distinct, and separate.
Not all projects have work for unskilled contributors. Why should we cater to them (who on the whole do <1% of the work) at the expense of the skilled contributors? Particularly the most senior contributors, who in practice do 90% of the work. We don’t build houses with toy hammers so that your grandma can contribute.
I’m not saying we shouldn’t make tools which accomodate everyone. I’m saying we should make tools that accomodate skilled engineers and build simpler tools on top of that. Thus, the skilled engineers are not slowed down and the greener contributors can still get work done. Then, there’s a path for newer users to become more exposed to more powerful tools and more smoothly become senior contributors themselves.
You need to get this point down if you want me to keep entertaining a discussion with you: you can build the same easy-to-use UX and drive it with email.
I was under the impression that git + GitHub are exactly these. Git and git send-email for those who prefer those style, GitHub for those who prefer that. The skilled engineers can use the powerful tools they have, while those with a different skillset can use GitHub. All you need is willingness to work with both.
I’m not questioning you can build something very similar, but as long as e-mail is the only driving power behind it, there will be plenty of people who will turn to some other tool. Because filtering email is something you and I can easily do, but many can’t, or aren’t willing to. Not when there are alternatives that don’t require them to do extra work.
Mind you, I consider myself a skilled engineer, and I mainly use GitHub/GitLab APIs, because I don’t have to filter e-mail, nor parse the info in them, the API serves me data I can use in an easier manner. From an integrator point of view, this is golden. If, say, an Emacs integration starts with “Set up your email so mail with these properties are routed here”, that’s not a good user experience. And no, I don’t want to use my MUA to work with git, because magit is a much better, much more powerful tool for that, and I value my productivity.
I’m pretty sure the whole point would be that the “shiny UI” tool would not expose email to the user at all – so the “plenty of people” wouldn’t leave because they wouldn’t know the difference.
So…. pretty much GitHub/GitLab/Gitea 2.0, but with the added ability to open PRs by email (to cater to that workflow), and a much less reliable foundation?
Sure. What could possibly go wrong.
I don’t think you can count signing up for GitHub if you’re not counting signing up for email.
If you’re using
hub, it’s justhub pull-request. No context switchingIf you’re counting signing up for email you have to count that for GitHub, too, since they require an email address to sign up with.
Using GitHub requires pushing to different repository and then opening the PR on the GitHub Interface, which is a context change. The git-send-mail would be equivalent to sending the PR.
git-send-email is only one step, akin to opening the PR, no need to push to a remote repository. And from the comfort of your development environment. (Emacs in my case)