Hacker Newsnew | past | comments | ask | show | jobs | submit | Skinney's commentslogin

> You work for money.

I work for money because I need food on the table and a place to sleep. It doesn't motivate me much more than that. In fact, I wouldn't even call it motivation. It's a requirement to live.

There have also been studies that have found that money stops making people happier or more motivated once their yearly salary exceeds a certain amount (the equivalent of 700.000NOK here in Norway).

Some people are primarily motivated by making as much money as possible, sure, but most people I've worked with have found someplace else to work once their current job stops being interesting.


> Having a register machine doesn't seem very useful...

Requires fewer instructions, so potentially faster evaluation, which is good for short-lived programs that ends before the JIT kicks in.

Stack machines requires less space per instruction, however, which reduces the size of the program (faster to load).


If it works anything like what we've got in Norway, they take a rough percentage, and once every year when the taxes are filed, the IRS equivalent charges or repays the missing amount.


That's how it works. You indicate if you want the company to take the tax free threshold (you only want to do this for one job if you have multiple), and then you can also elect to tell your employer(s) an estimated taxable income and they'll use that. Otherwise they just assume your income from that job is your taxable income.

At the end of the year you file online and put in your deductions, which hopefully cover any other taxable income (capital gains, dividends, interest, etc.) if you didn't give your employer a higher figure. Then you pay if you're owing or get a refund if not.


Litestream is already backing up your changes, so synchronous=normal seems reasonable.


What sort of IDE plugin are you thinking of? As long as you have a git plugin it should work just fine (if you're thinking of something similar to github/gitlab plugins then I don't think there are any, but I'm not sure what those buy you).

It's possible to setup CI: https://app.radicle.xyz/nodes/ash.radicle.garden/rad%3AzwTxy...


It's "just" git, but you push to a special remote which will synchronize your repo on a p2p network.

There's also a CLI for issues and pr's, which also get's stored in your git repo.


Anyone using radicle for a project with external contributors?

I've tried it with some of my projects and it seems promising, but I wonder what it'd be like to use it on one of my more successful projects.


Hm, I thought Radicle does not have a way to create a private repository. E.g. your repository, code, and issues are always publicly visible.


This isn't true. You can setup private repos. Here are the docs.

https://radicle.xyz/guides/user#3-selectively-revealing-repo...


If I’m deploying a new version of my app, the typical managed solution will spawn a new server instance with that new version, and once a health check has succeeded a couple of times it will reroute trafic to this new instance and kill the old one.

Previously this would be problematic, as the new instance might miss changes made by the old server. Is this fixed by these new changes?


It seems to me that you need to think about your server as the production database, rather than a web server instance that can be trivially spawned by a management layer.

When I deploy a new version of my python/sqlite web app, I do not replace the whole machine. I just upgrade the python package and restart the systemd service.

If I wanted to reduce downtime I could probably figure out a transition using SO_REUSEPORT. During the transition the old and new processes would be using the db concurrently, so the app would have to respect that case. If part of the upgrade requires a db schema change then I’m not sure how you could avoid some downtime. But I don’t know if it is possible with traditional dbs either.


I don't think this is trivially fixed since you can still only have one writer that is holding the lease.

Your new service will come up, but it won't be able to get the write lease until the previous server shuts down. Now you have tools to detect this, stop one writer, and start the other, but the service will likely have to experience some kind of requests queueing or downtime.


> Git repos (it's too difficult)

Sourcehut

> Startpage uses Google's index.

If they have enough users/make enough money, they'll make their own. Ecosia and Qwant (both european search engines) are working together to make their own index.

In any case, even if a european is a proxy for an american service, you need to prove that there is a market for an european equivalent for change to happen.


TIL that Sourcehut is or has been moving to the EU/Netherlands, thanks!


They have moved to Netherlands. They were planning, but Murphy knocked (kicked?) on the door as a massive DDOS, so they expedited the move, a lot.


For git there's also Codeberg

https://codeberg.org/


+1 for Codeberg. I switched also to them. Theo habe also an alternative for GitHub Pages


> Sourcehut

Is it there yet?

> Notice: sr.ht is currently in alpha, and the quality of the service may reflect that. As such, payment is currently optional for most features, and only encouraged for users who want to support the ongoing development of the site. For a summary of the guarantees and limitations that the alpha entails, see this reference.

https://sourcehut.org/pricing


I've used it for a few years and it's been stable and without issue. builds.sr.ht is the best CI that I've ever used. I think the only time it has been down has been due to DDOS.

Would I run the git server of a multi-national bank on it? Probably not. A standard SAAS? Yeah if my team felt it was important to use EU companies.

Otherwise you could also self-host with a VM, then you can use gitea or gitolite with systemd oneshot services.


> If they have enough users/make enough money, they'll make their own. Ecosia and Qwant (both european search engines) are working together to make their own index.

"There might be an option in the future if there are sufficient users" is a quite different milestone compared to fully switching away from US-based services.


Keep user information in one database, keep user _data_ in another.

It all depends on your app, really. For some apps the above won't make sense, but maybe it would make sense to keep one db per org, or something like that.


You can also use a different but similar tool e.g. use sqlite to keep user information, use duckdb to keep user data. I find this combo very effective since sqlite is best as fast btree based indexed operations and duckdb is best at multiple row based aggregate computations (get me user X vs get me all users with property Y).


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

Search: