The absolute dumbest shit here gets up voted regarding Linux.
No dang, I don't care about the spirit of the site when absolute ludicrous mindrot garbage is up voted here constantly. You'll note on the Wayland thread that, despite being the 30th Wayland thread, the only substantive reply agreed with me. It's a joke.
Don't worry, I'm changing my password to a random guid, you'll be free of me in 45 seconds.
lol, as a distro package maintainer, I've literally stopped packaging and stopped using software that uses autotools. Given me meson or give me a software compiled in a respectable language, or preferably, death. I'd take cargo and its crates.io namespace warts every day over autotools, and twice on every day of the week.
Oh never stop HN. I should never use anything except 30 year old gnu tools because they've definitely never gone through development lulls, or changed ownership. Etc. "They'll still work in years", as if exa doesn't still work just fine. People here just say the stupidest shit without an ounce of consideration of how ignorant it is.
Man, HN really just can't handle harsh truths. Do I need to go dig up 6 year old issues about this? Or the half dozen times it's come up on HN over the last 5 years?
I love Rust, I'm a big fanboy, but we need to stop pretending there aren't glaring blind spots.
Thanks for at least offering something interesting. To be honest, the state of crypto is past what I can keep up with, but that gives me some concrete foot-holds to look into Phonon vs Lightning more.
This issue has been pointed out so many times, it's clear it just doesn't matter, really, to anyone on the Cargo team. Meanwhile, years after this criticism was first offered, the problem remains, only more entrenched.
Please don't scorch me HN, this isn't an endorsement, just a question for thought -- but isn't this one of the things Lightning is sort of meant to solve?
lol, literally less than 20 seconds.
> Then, when does reconciliation happen? When either party goes online? What if it is not a closed loop system? Then, reconciliation needs to happen for both parties independently. How long can either party stay offline and continue to make transactions? Is it both send and receive or only send on one side and only receive on another side? What if one party (merchant/receiver) is more likely to be online (almost always). Does it just become online payments problem then? NFC tap and pay is exactly this scenario.
Again, literally the exact problem statement and value proposition of Lightning, but stupid, stupid me for daring to mention it here, I guess. Feel free to ignore that the idea behind Lightning could be useful without being tied to crypto, but can't possibly have a conversation about that. Nope.
I absolutely love that Texas has managed to convince their citizens that the states' problems are definitely most certainly all those California transplants (that they encouraged to immigrate) and not the states own self inflicted bs.
Don't they get tired of being wrong, too? I've used software from these types of people and their stuff crashes and segfaults as much or more than their equivalents, certainly than the rust equivalents I use.
Did you not see people warning against this previously?
These warnings are like "make backups", "use a password manager". Afaict, people are either going to, and have, or they're going to be lazy and assume it won't hurt them until it does.
Hard to trust this when the conclusion is to use NFS instead of VirtioFS. I don't buy that NFS over network, to a VM is faster than 9p, and certainly isn't faster than VirtioFS. Though "share from the VM" is good advice for NFS, since you can just reboot the guest when some part of NFS inevitably hangs (not-so-distant trauma here, including learning how to force power-off when shutdown is broken by NFS).
I can't believe I bothered reading that. Luckily the discussion of the client side encryption feature request gave me enough context to immediately stop.
As with all of these types of boards, it ships with some oddball u-boot bsp version, and from what I can tell upstream efforts for u-boot are going slowly (https://lore.kernel.org/u-boot/?q=lichee). YMMV. If you want to play ball with the shipping LicheePi4A bsp u-boot, you have to specially put firmware bins in /boot so that u-boot can slurp em and load em.
I'm supposed to be forgetting this. Maybe passing on the trauma is my way of healing.
Something I am (why, someone stop me?) curious about is the differences in toolchains used. I've seen it reported in several places now that stock GCC produces noticeably inferior code to the optimized th1520 toolchain. Is that going to change/be upstreamed/ etc?
I personally would wait to show it until it's usable. The self-hosting docs say "forthcoming". I'm quite interested to learn more, whenever that might be.
No dang, I don't care about the spirit of the site when absolute ludicrous mindrot garbage is up voted here constantly. You'll note on the Wayland thread that, despite being the 30th Wayland thread, the only substantive reply agreed with me. It's a joke.
Don't worry, I'm changing my password to a random guid, you'll be free of me in 45 seconds.