ignaloidas

This doesn't represent Lightning network, which is used for smaller, quicker transactions later synced onto the main Bitcoin chain by transferring only the differences between the nodes to save on transaction fees.

It is not backed. I cannot exchange dollars into political US power or GDP of US.

Yeah, I'm pretty sure that Federal Reserve hasn't been really backing the dollar. The gold is there, sure, but it isn't connected in any way with the value of dollar. The Federal Reserve surely doesn't have enough goods to back all of the dollars in circulation. The fact that US industry is trading by dollars doesn't change the matter. There are quite a few businesses that trade by bitcoin.

You can't eat a dollar too. Intrinsic value of a dollar is smaller than a piece of paper, as it's not even that good for taking notes. It's valuation is the same: based on artificial demand.

Oh, like Ackermann function[0]? Because I wouldn't want my server try to evaluate that.

[0] https://en.wikipedia.org/wiki/Ackermann_function

It seems it was a common solution to the external crash testing performed by publishers: https://www.youtube.com/watch?v=i9bkKw32dGw

Wrong date on that page. That's Dec. 2, not Jul. 2

The killing isn't actually the fault of Android itself, but the smartphone vendors that try to push the battery time metrics to the max. Battery management from Android isn't that bad actually, but the vendors will always find a way to fuck it up. I really liked this insight from "Zombies, Run!" developer: https://news.ycombinator.com/item?id=18901006#18902273

>>>Private messages (...) are prohibited in Ham Radio

> Broadcasts are also prohibited in ham radio.

Wait what? Isn't any message either broadcast or private?

Bitcoin transaction is basically a broadcast, which you can analyze freely. No decryption, just encoding and signing.

>Considering all the successful software that's been written in Go, they weren't exactly wrong.

How much of that software doesn't use Go's internal generics?

This is dumb. Many products have dumb names, we just got accustomed to them, i.e. git. If you are hating only on this specific meme - I present you SmolV - the leading(and only?) SpirV compressor. If you aren't going to use good things because of naming, then you deserve to only use bad things.

ARM servers at scaleway actually start at 3euro/mo. I find that others have a bit more difficult setup the server. Finding the best auctions isn't the best way to spend your time in a startup. You are better of doing something that improves the quality of your product, and until some point, the server quality/price isn't your concern at all.

I see a lot of linode recomendations here, but if you are looking at mostly European audience scaleway.net has very cheap VMs starting at 2€ per month, while not being that much slower than linode

Technically python doesn't have multiple return or multiple assignment, it is just automatic tuple packing/unpacking

Meta: is "The Swiss Army Knife of $Something" the new "$Something for humans" ? I really hate these phrases as they technically can be put in front of almost anything and stay semi-accurate, but not give any additional information, besides being marketing-speak

> Claiming you don't clone the repository to your local PC is just false and will probably take more time than it does on GH.

I clone the upstream repository first, if I see a project I want to poke at, I don't instantly fork and clone my fork.

> > Excuse me, WTF? > This is what I ask every time I see someone saying e-mail is an okay way to do contributions, continuous integration and issue tracking.

I think you forgot this: "It lets FOSS be vendor independent, it allows big projects to exist. Linux, PostgreSQL, *BSD, even git itself, uses email to collaborate. Clearly there is no negative impact as these projects are so successful."

> It negatively affects basically every component of development for everyone not accustomed to the bad tooling.

There is such thing as a good contributor. Some rando that quits on not knowing how to use a bug tracker isn't a good contributor. Somebody who takes time to learn how to use the tooling will be more beneficial to the project, than a bunch of one-time contributors whose contributions just take time to look at from main contributors. I think that having some barrier of entry really helps to conserve the time of the maintainers.

> > Secondly, that puts all of the FOSS projects in one basket

> You are out-of-touch to the possibilities available right now, Gitlab can be self-hosted.

You can build your own Chromium, but that doesn't change the fact that the web engines are getting centralized. "I only need to test on Chrome" and such. The same with hosting. The fact that you can self-host Gitlab doesn't change the fact that if everyone is hosting on Gitlab, you are putting all of the tooling to one vendor. It will devolve into "But it works on Gitlab CI".

> Sending bug reports to those companies using GH/GL has been a way better experience for me.

And would you think of the maintainers? Managing GH/GL bug tracking is difficult, as it lack features. No advanced statuses means that maintainers have to rely on hacky statuses using labels, which can get hairy really quick.

> So what? There's a lot of old and bad "protocols" we've killed.

Oh, like HTTP and FTP? Oh, wait, we're still using those. Maybe IRC? Oh wait, that is still used in development. Should we kill all of those? They are definetly old and have problems. You know what is also old and has problems? Walking by foot. So lets stop walking by foot and use bikes everywhere. Oh, you can't ride a bike in a building? Seems like we'll need to change our buildings too!

So you think that it is better to everyone to know everyone's conversations rather than everyone to know just their conversations, because someone could have more conversations and that is not fair. Now that is actually dangerous, because if someone wants to misuse your data, you'd rather them have only your conversation to them, not your conversations to everyone.

>How do you deal with continuous integrations and making sure things like CLAs are signed? How does issue tracking integrate there?

The same way that you do that on github: many mailing lists can send webhooks on email received, and then it's up to your CI and CLA bot to respond to that email accordingly.

> You mean you don't create a fork by cloning the repository onto your PC when using e-mail?

I mean that you must open up a browser, open the main project repository, click fork, and wait for a minute for the forking to complete so that I would be able to push to my github fork now. I don't need to waste my time doing such stuff when using email.

> Or that somehow `git send-email` is harder than `git push`?

`git send-email` is just as easy as `git push` and I see additional benefit in it integrates you message to maintainers too, not having to write it separately

> I'd gladly remove `send-email` from git

Good luck trying to do that, Linux, arguably the biggest and the most important project out there, the one for which git was originally created, still happily lives using email and mailing lists.

>for it's negative effects on FOSS, it's clearly making people think it's somehow nice to use or start using.

Excuse me, WTF? How is it negative exactly? It lets FOSS be vendor independent, it allows big projects to exist. Linux, PostgreSQL, *BSD, even git itself, uses email to collaborate. Clearly there is no negative impact as these projects are so successful.

> All of them are absolutely terrible to use.

My experience is quite the contrary. While the interfaces aren't necessarily the most beautiful thing you've seen, they have all the most common actions easily reachable. Sending bug reports to Mozzila, PostgreSQL, etc. was a good experience for me.

> The sooner all FOSS migrates to Gitlab the better.

Have you've even read the first comment of this thread? It is asking about distributed git. All of the FOSS migrating to Gitlab is a highly negative thing in my opinion. Firstly it doesn't leave space for using email, which a lot of big projects have accustomed to using, and migrating to another workflow would be a massive burden, and could discourage old contributors from contributing. Secondly, that puts all of the FOSS projects in one basket, making them more vulnerable for intervention. If <nation> wanted to deny access of FOSS projects for <another-nation>, it would just have to exercise power on Gitlab, which could fly under the radar of mainstream media, while if it was hosted on plethora of platforms <nation> would have to exercise power on all of those, which definitely couldn't go unnoticed.

Gitlab and github issue tracking isn't even that good. Many bigger projects use many states of bugs, like confirmed, in_progress, duplicate, etc. Github and gitlab just have open/closed, and that isn't good. If you want to find some bug to work on, it is a lot easier to filter on confirmed, than to look through the open bugs to find one that is confirmed, isn't being worked on by someone else, and isn't a duplicate of a bug that someone else is working on. All that Github and Gitlab bug tracker has is pretty UI, which doesn't mean good UX.

>we're stifling FOSS' progress by using tools majorly out-of-date.

The fact that those tools were created a long time ago, doesn't mean that they just stayed in those years. Tools are constantly being worked on. Linux was started in 1990s. Is it majorly out-of-date? I wouldn't say so. If it is, why are we all using it?

So you are saying that sending an e-mail is seriously cumbersome? Excuse me, but for me it is a lot more steps from local edit to a contribution using Github. For Github I (1) have to create a fork (2) set it as a remote in my local copy, or if I forgot how to do it, (2.1) pull another one and copy my changes to it, (3) push my changes to my fork, (4) open a pull request in Github, which takes 3 context switches. Meanwhile for email I (1) look at README to find the email of development mailing list, (2) set it up for git send-email(https://git-send-email.io/) and (3) send my patches upstream, all with me staying withing my editor with an integrated terminal. No need to open up gmail or thunderbird, or even mutt or aerc. Contribution workflow is a lot more streamlined. If you don't like mailing lists for issue tracking, there is git-bug or plethora of different bugtracking software for you.

Mailing lists. Many providers, easy setup. Pull requests are an artificial addition to git workflow, it was designed with email patches as the main way to send contributions. Bug tracking is fine with mailing lists too.

Git is DVCS, D means Distributed. Anyone can run their git and manage incoming contributions by email, which is distributed, and what git is built to use. See https://drewdevault.com/2018/07/23/Git-is-already-distribute...

You can still run MacOS in VM even when using AMD. https://www.youtube.com/watch?v=ATnpEOo3GJA

Power reserves do not generate power, and they do not provide power in the orders that a nuclear power plant provides. If you can build something fast, it is not necessarily good. I think 10 years for a nuclear reactor is a bit of a stretch though. I think currently the initial infrastructure with a reactor or two is built in around 7 years, while adding additional reactors might take 3 or 4 years. And the building speed is quite fast in comparison I think. If you think it in terms of watt per year, a decent sized nuclear reactor gives 430MW/yr while building solar plant of that size that fast is quite an endeavor to take. Solar power does have the advantage that you can plug it in nearly instantly, but in the long run it cancels out.

Just to make reasons to move to ipv6

Osu! also uses IRC for it's game chat, but it's not obfuscated . IRC is good enough for game chat, you don't really need anything more, unless you want to integrate voice-comms too. Actually, I once made multiplayer-over-IRC in a game jam, as the interface is so simple and flexible.

Firefox containers go around that nicely, as Economist offers several free articles per month

If you have good manners, Python codebases can easily grow over 100kloc mark. Static type annotations, using descriptive variable and class names, type checks on user input(esp. libraries) makes growth safe and simple.

To see more of this - sourcehut[0] uses most of these tricks and is open source so you can check out how they are used

[0] https://sourcehut.org/

I think the title is also misleading, because the boats float, just too well.