Walkman

Sorry, but you don't have no clue what you're talking about.

Python is an imperative language by nature, and lamdba is very uncomfortable to use for anything than a simple expression. You can use functional elements up to a certain degree, but it will be a pain if you try to force it to be a functional language; you simply can't go very far with it.

NO, Python is not simple at all, especially nowadays with all the asyncio stuff and tons of new features in 3.4+. One can't even follow what's happening with the language.

I don't understand where this nonsense is coming from. Probably ignorance? You might not know too much about it to understand how huge and complex Python is.

I also like what Rob Pike used to say: "A little copying is better than a little dependency."

The big difference is that Markdown is way simpler, you can read it reasonably easy with Notepad even, and this is why every reasonable editor can Render it preview it, export it. Even browsers or small apps can show a HTML rendered markdown. There are even standalone Markdown editors, but there is no standalone org-mode editor.

1Password is an order of magnitude better regarding the UI and UX.

It might not have been his idea at first to help, I found this tweet: https://twitter.com/mabzmagz/status/1014251869760249856?s=21

This is how Flask actually started. Armin wrote an April fool's joke but had no code (at least not much) at that point, but nobody looked the code! They just liked the concept and the documentation, so he had to implement it afterwards :D

PostgreSQL's is very concise, clear, to the point, but still very detailed. Has examples! https://www.postgresql.org/docs/10/static/index.html

Here we go: https://gitlab.com/gitlab-org/omnibus-gitlab/issues/3615

Thanks for the tip, but this was one of the first things I tried beside

    gitlab-ctl reconfigure && gitlab-ctl restart

I don't think so. The problem was that unicorn was not listening on IPv4 by default, but it was before 11.0. Weird.

If you are using the Omnibus package on Ubuntu, don't upgrade! It just broke my instance. and can't find out what's wrong. Great features... It was a big mistake to trust GitLab, I already predicted they will have problems.

For all the wonderful people -1-ing this, care to elaborate why am I so wrong?

No. It changes the essence of how we develop today. You don't even have to think about instance types or anything, you only have to think about your code, everything else is someone else's problem.

Terrific idea! Very nice act.

     ~/.ssh/config

is really simple, I never needed anything else.

For URLs, I use bookmarks, that's it. You might actually need more, or you might think you might need more :D but I don't think so.

Also different URL collections have different places, for example I collected all our developer documentation URLs in a single wiki (Confluence) page with a permalink and put it under an easy-to-remember internal domain.

That's not a system at all.

> My sentiment exactly, but weren't you building up an argument in favour of SystemD?

Fair point LOL :D

> >- The amount of stuff systemd is doing for you is insane. > Yes.

The emphasis is on FOR YOU, so you don't have to do it, which is a good thing IMO.

No, sorry. We are building our appliance. We are using Ubuntu as a base.

My day job is to build a custom operating system with systemd. Here are my thoughts about this:

- The amount of stuff systemd is doing for you is insane. For example, I just learned the other day how the systemctl stop command works; first you can send any signal you want to the process from a script (ExecStop=), then if that fails and the process is still running, systemd takes over, sends SIGTERM, waits for a bit (TimeoutStopSec=) then sends a SIGKILL, optionally handling child processes. I wonder if every single of your shell "init script" handle shutdown that nicely...

- I hear this complaint over and over, but systemd is NOT a monolith, you don't need to use every component. I have a system only with systemd as init, systemd-timesyncd (because I prefer it over ntpd) and that's it.

- It has bugs, yes, every software has bugs. We even hit multiple of them, and some of them was fairly unpleasant and hard to find, but it can be known after a bit of digging, because development is on GitHub. Also I'm fairly sure your shell scripts don't have any bugs in them...

- Shared knowledge. I never heard this argument, but you can jump to any other system and understand what's going on immediately if everyone uses the same init system. This is a huge advantage. Fragmenting the landscape with programs which inherently do the same thing just a bit differently is just a bad idea. I also hate split of talent and split of energy. Also, why on earth would you change to another init system ever? Or why would you ever change to an init system you don't know?

- Boot time is way better with systemd. With sysvinit, there is no parallelization. You have runlevels and that's it. I never used more than three, but I use multiple targets (own custom target also) with systemd, because it's easy and you can finally name them and debug them and see the dependency chain for every target.

- Sometimes we need to dig in to old sysvinit scripts and it is a terrible experience. It has still a lot of stanza-like parameters IN COMMENTS (LSB headers). Great idea...

- Systemd DOES NOT break backward compatibility. It can use existing sysvinit scripts. Actually it even default to those if there is both a .service file and init script.

- "One of the critical reasons against systemd concerns the lack of portability to other Unices, and the associated risk to see Linux-based systems detach from the UNIX world."

Anyone seeing the irony here? :D

- Man pages of systemd are quite nice! It's easy to learn from them. You don't even have to google, just check out the relevant man page.

I never understood systemd hate, but I guess it comes from ignorance and lack of willingness to learn about modern system design. The people who made the fork are just a bunch of hissy kids or stuck in stone age who are lazy to learn a new system IMO.

I agree with this, but the cost is centralization and single point of failure.

> What’s your server’s uptime? Is it highly available?

Who cares about uptime, when you use a server alone or with a small team? It can be down for 10 hours and you would not even notice.

You don't understand what you need.

> How often do you patch?

I patch the machine multiple times a week with some "apt update && apt upgrade" which takes literally less then a couple of minutes a week.

> Do you test them first?

I don't need to because I'm using ZFS and make a snapshot before upgrades, so in case of a disaster (which already happened multiple times) I can roll back within minutes, which happened multiple times, once when the machine didn't even booted.

> How is your security team in general? Do they monitor for stolen credentials? Do pen-tests? Watch for network scans and attacks? Look for weird traffic patterns?

You don't need any of that. If you think you do, you think you are far more important than you really are. Maybe framework authors or super-popular library writers would need to worry about that, but self-hosting makes you an order of magnitude lower chance of being a target.

> Is someone always on call? What are they experts in? How do you get support?

We might not talk about the same thing...

> And that’s not including the network effects of having so many projects in the same site.

This is the only valid point you came up with.

I feel like everybody is overestimating the cost of self hosting. I run my own instance of GitLab, but the "costly" part was setting it up and making backups. Since then I just "apt-get upgrade" and there is a new version and that's it. Since I set it up, I haven't touched any of the configuration files.

The availability guarantees are much easier to keep for a small team than for thousands, so you don't really have to worry about that either.

why on earth would I want this instead of a local service if I absolutely need (which I don't with clean architecture and clean code)

not really a good idea

It's not an article, it's a rant. Probably not worth the time reading it.

What is the use-case for this? I read and agree that writing HTML or JavaScript is too costly for wireframes and this is why wireframe tools are handy, because you can cheaply sketch out plans or ideas. But this is in JS, so "drawing" with this would be costly.

I can see that it can be used for the fun look, but other than that, what's the point of this framework?

I'm not saying people should not show projects or doesn't belong here. I really like "Show HN" myself, but why did this particular project made to HN front page is what I don't understand.

I agree, but pretty sure that 90% of the average users doesn't need geo-replicated safety. It's nice to have, of course, but does it worth it? You can buy a couple of HDDs for multiple backup copies and it's an order of magnitude cheaper.

I have a 32 TB machine sitting under my desk. It will return it's cost in less than a year. Storage is very expensive in the cloud.