dpc_01234

And there needs to be someone willing to pay for the water more than the electricity used, transport and capital and operational cost. And such price needs to be lower than alternatives. No one is going to build such an infrastructure for charity, or overpay for water "because it helps balance the grid".

The thing with miners is also that they are highly portable. The moment it's banned, heavily taxed or simply better uses for electricity out-competed it, they will pack them on shipping containers and off they go, so capital risk is lower.

The fact that cryptocurrency users are willing to subsidize production and deployment of such a flexible and portable load balancers is an opportunity, irrespective what one thinks of cryptocurrencies, but most minds are too narrow to go over "uses electricity == bad" narrative.

Mining is actually good for stabilizing grid, which is very important for accommodating renewables.

Yes, mining is "wasting" electricity, but it's not a full picture. Sometimes being able to "waste" electricity is actually very useful. Mining is a immediately reactive and flexible load on the grid, and in a free market , at the near-perfect competition, mining naturally gravitates to places where electricity is abundant and can benefit from doing something productive (burning off methane, capture over-production).

People who wish to ban or "harm" mining have no idea what they are talking about. Electricity is not something that can sit in a basement and wait to be used indefinitely if someone doesn't just "waste" it. That's just not how things work.

From the perspective of cryptocurrency users banning also completely doesn't matter. If you ban mining in place X, then too bad for the miners in X, mining will just move to a different location, where possibly electricity might be less clean (not from renewables), and on the global scale things just get worse.

> Which you think it is depends on what you value.

Sure, but more so - what software you use. AFAICT most complaining is about Windows software and web.

Windows is getting crappier and crappier because it ceased to be an important part of Microsoft's empire, and web... is web, went full stupid on JS and attracts most newcomers.

On the Linux and especially CLI side everything seems to be flourishing.

The blockchain and LLMs parts in particular fall flat in this article. Blockchains are attractive because they are novel and can be easily monetized (usually by taking money from invest... well... suckers). Their wastefulness has little to do with anything. And LLMs are... just useful and promising. I'm personally deeply reserved about near term possibilities of LLMs, but it doesn't stop me from paying $20/mo for ChatGPT and using it as a convenient search engine for programming and other things.

And generally this doom-saying by people like Jonathan Blow doesn't reasonate with me at all. Sure there is a lot of waste. But also software is better then ever was. 3d graphics are better, programming langauges, Unicode support, software development process, hardware is faster, all the clunky C tools are being replaced with modern equivalents in Rust/Go with way better usability, cryptography and security are better, desktop environemnts are better, file systems are better. I could go on.

In my mind the only things that are getting worse are the commercial stuff: web sucks and stole the thunder from native apps and Windows/MacOS are degrading.

I wish Apple could do 90% cut. Serves their users and developers right.

If you don't think it's worth it, no one is forcing you to use it or developer your software for them. :)

Nix dev shells are far better than container for dev work.

I think there's something to it. More important HTMX is just new and different enough that it needs time to be picked up by the industry, BUT indeed it does largely eliminate what is commonly considered strictly front-end work, and thus forces teams to change their composition and division of responsibilities.

At least where I worked there was often a frontend vs backend divide where some devs would write backend logic, and some others would worry only about consuming backend APIs to get the UI to do certain thing. The APIs is the contract and interface between the two sides and a natural place to divide responsibilities.

Now, with HTMX, the divide is gone. The backend generates and swaps the parts of the UI, effectively driving the UI/UX directly. This cuts tons of JS out of the picture and couples (not necessarily in a bad way) backend and frontend.

If you look at a popular YT video: https://www.youtube.com/watch?v=3GObi93tjZI , the result of HTMX rewrite was "JS guy left".

So in larger teams switching from something like React to HTMX largely turns everything upside down, not just on technical level but on how people work and collaborate.

It would be far easier for new teams and projects to go HTMX route, where they can start and keep hiring people who are fine in a new model.

> I sometimes wonder if the Nix stdenv does too much.

Yeah, NixOS is a Linux-based OS, and historically most of the system stuff is C/C++. So `stdenv` is just that - an abstraction for "a standard Linux environment with a working C toolchain to build system packages". I also tend to just use `runCommand` when I can, but even when building things like Rust, Python or JS, quite often there's some little plugin/package that needs to be built with a C compiler, and then `stdenv` comes handy.

> I think I understand Nix, too.

I don't think so, not from what I'm reading. Not fully. Just comparing with Docker is a sign of limited understanding. Nix is not really a Docker competitor. You can run Nix stuff in a Docker, and it can build you a docker container image as well. Orthogonal. It's just so happen that basic applications of Nix overlap with what Docker is often used for, so comparing the two might seems natural. But Nix is more and more fundamental: Nix is a shared language for software composition. Nix creates a Linux OS for me, prepares custom ISO with my fav. stuff built-in, prepares my home dir, maintains my servers, configures services I use, makes me a dev environment I can share inside my project, future-proofs ad-hoc scripts I wrote, builds me docker containers, builds rpm&debs, makes me cross-compiling toolchains, and so much more.

Anyway, Nix does have an usability problem, but it's not fatal.

It's not worse than usability of e.g. git, or even usability of Docker.

Yeah. Docker. People now consider Docker a bread and butter of SWE, but there are still plenty of people that don't know how to use it, or need lots of help using it, and not much more than 5 years ago you'd have to drag your team and explain to everyone why it's beneficial to use it. And when things go south it takes quite a bit of understanding of the under-the-hood machinery to figure things out.

And there are plenty of devs who know like 5 commands to handle git + github UI and when anything goes wrong need help. And people complain about UX of git every week on HN.

Usability is 90% familiarity. Once you have enough people who know X well, they help people who don't and live goes on.

Once you build a good mental model of Nix, it's actually very simple, elegant, natural and very usable. The error messages and other-UX-stuff sometimes suck, but it's surface level and fixable (thought requires lots of dev work).

At this point I can't even imagine working without Nix, and giving up on things it allows me to do. It's really like a super-power. And it's been a great accelerator for teams and project I've introduced it to. I could maybe see something even better just replacing it, but once you really get Nix, there's not going back.

The atomicity in the bash version can be "simply" achieved by copying the file to a temporary, modyfing it, then using `sync; mv; sync`, right?

Eh, such a teenage level criticism of capitalism. You write like e.g. SQL or nosql hater, lacking the deeper understanding, and trying to write off the whole thing upfront and narrow your definition of big thing to a particular implementation you had dealt with.

Capitalism is very much like a programming tool/technology/pattern one can employ. It has pros and cons, isn't perfect, but can be "implemented" well or poorly.

We probably both agree that the implementation around us sucks big time. But it doesn't have to be that bad, and also needs to be compared with actual real alternatives.

It's not really about capitalism. In capitalism capital is producing value and owners get rewarded. How is destroying a platform making tons of money capitalism?

The whole thing is caused by "shortermism" & "managerialism". The group dynamics are such that the company is not really owned by anyone in particular that would be attached and interested in its long term profitability, only by very distributed shareholders or entities interested only in very short term profitability, hoping to flip it in a matter of weeks. The power over company is in the hands of managers which also all are interested only in the most short term goals like their bonus or getting promoted.

Anyone able to compare with buildjet? Happy to see more competition in the space. :)

I think you're right. Reported on Syncthing forum. https://forum.syncthing.net/t/entropy-of-untrusted-device-sc...

Pole here. For the lazy like me in the US: Kasias Pierogi from Costco are yum. Fry on a pan with Ghee till golden brown. Store frozen. Can be fried from frozen just fine. Quick and convenient.

I don't really see anything miraculous here, other than "GitHub PR review UX sucks in comparison". Things like AI help and extra linters etc. are something that a each project has to figure out on their own, and e.g. I maintain projects that use Nix dev shells to optimize and streamline the dev experience by a lot, even before things hits the change review stage.

Github's PR review flow just breaks down for anything non-trivial. People have been complaining about it for years and suggesting a lot of relatively low hanging fruit improvements.

The rest is about the culture of CRs some of which could benefit from built-in support, but some doesn't need it.

Back in 2005, when I was still living in Poland and working as a developer after graduating uni. I started contributing to a GPLed L4-microkernel-based hypervisor targeting ARM-based embedded devices called Codezero. I was just interested in micro-kernels and it allowed me to play with an actual working project. I've got a job offer from the founder and worked remotely on it for 3 years, when the company was acquired by nVidia and I got a H1B and moved to Silicon Valley, which pretty much changed my life.

So Meta is basically selling these headsets at the loss or near loss, IIUC, hoping to make it up on building network effect, tech and the store fees, as usually these sorts of hardware platforms do, and then Valve comes in and effectively hijacks the platform turning it into an accessory for the SteamDeck.

As someone that happens to own both (I love the SteamDeck, think as a VR a gimmick) I need to try it out soon.

We need to fork libc/posix, name it like `libc2` etc. fix versioning and start making changes, while allowing legacy software deal with the old cruft.

It never gonna happen if we're waiting for some committee to deal with it, because they will be too afraid of breaking backward compatibility.

I'm very curious if anyone could share reasons why Smalltalk and the system they are using here didn't "win" in the "marketplace of ideas". Performance? Native integrations? Developer preferences? Or because it was comercial and free / open source tools won even though they were less sophisticated?

I can already see that some of the ideas mentioned were completely wrong, like "buying objects on the market". "Reusability" on the object-level is very low, and nowadays we can clearly see that "re-usability" is better achieved on the "module" level (npm, cargo, etc.).

I'm like half-way through the video and basically I can see the naive believes about potential OOP that nowadays we kind of know didn't work (re-usability through inheritance, ignoring the complexity explosion etc.)

But even ignoring all this, the tooling, JITs, portability - all seemed quite nice and it's surprising that it seems all gone.

Signal should be able to bring in some revenue other than donations. Premium features that don't compromise the privacy? Premium stickers? Extended emojis only if one paid $1 etc.?

Without digging into details: this seems like a a great idea. It's a cooperative, advisory optimization that can't really be gamed for permanent cpu time gain. A hint to scheduler that indicates that letting a process run just a tiny moment more might be good for overall system performance.

I disagree. Unfortunately there are good and rational reasons to coalesce around standards. Hate k8s all you want, but you hire a new SWE, what are the chances that they know how to work with your bespoke infra vs they used k8s before.

Now - there are decisions to be made around what is really necessary and keeping things simple is often the right choice, but being able to hire people already familiar with thing is not something one can dismiss and say "Lemmings".

Similar things things apply in social aspects. You want to work remotely? Great, me too. But it doesn't change the fact that there is a lot of people who would like to work remotely, and less corporate envs that are comfortable with it (even if for dumb reasons). Which means you'll probably have to be paid less and so and so.

You want to change it? Make your own company, 100% remote and out-compete everyone. Easier said than done, unfortunately.

> It can sound controversial, but can we please stop with tipping altogether?

Yes, I'm all for it. But it would easier to do during times in which service workers aren't just barely scrapping by, and had more negotiating power.

I was initially thinking ... "OK, another monospace font (family), look nice", until I got to "texture healing" which really made me want to try it out.

I really like the idea of using different style of font for different things, but as primarily terminal user, I don't even know which terminals support it (if any), and then we would need CLI text editors support as well. But I think it's a great idea.

You can skip type system magic, and have people just keep introducing bugs that it would prevent over and over, writing more tests trying to prevent it, never quite succeeding, but overall "feeling productive" and "being agile" along the way.

Having said that - yeah, making good apis and abstractions that prevent mistakes takes time and some skill, and pays off gradually proportional to the scale and longevity of the project. And for certain things is not worth it. Being able to make a good judgment if enforcing something at the compile time / runtime / at all is worth it is part of the skill.

I have a Steam Deck, Steam Link and the Steam Controller (it does work) among other controllers. The ability to use any controller is awesome (Wireless DualSense is my fav RN). Steam Controller itself wasn't all that great, and I like the . And Steam Controller with a Dock acts as Link (unless I'm missing some other functionality).

> why the hell am I talking to raw socket APIs just so that I can read from S3

I don't know. https://doc.rust-lang.org/std/net/struct.TcpStream.html#meth... etc. were there for a while. Though I think that deadline-based timeouts would be way better to have. https://www.reddit.com/r/rust/comments/8b5krv/the_case_for_d... . Probably could be built around existing primitives. These things were never built/popularized because the community just jumped on async like some silver bullet.

I agree that building heavy duty networked services got easier with async, but at an expense of fracturing the ecosystem and dragging everything else into an MVP feature, which made things worse (at least in some respect) for other things. I personally don't do much web servers, and when I do I can just spawn lots of threads, terminate TLS with nginx anyway.

Again, I don't mind async on its own. I think it's great for what it is, and is useful when it's useful. But for decades tons of the web was built in Java, Python, RoR without async IO and it worked just fine. And I didn't have to play IO-type sudoku, and could expect that the most basic, native blocking IO is well supported, and not just an afterthought/wrapper.

I'm using the same setup and use 100% scaling and "Large Text" accessibility settings. Good enough for me, as a workaround so I thought it's worth mentioning.

Example from the recent past: I wanted a quick Rust code to stream s3 object, uncompress with zstd and untar the content to a directory. aws-sdk-s3 supports only async (tokio), tar crate only blocking, async-tar only async-std, async-compression only tokio. Hard to paper over it with `block_on` because of the streaming part. I don't remember what I actually did, but it doesn't matter - having to come up with a magic working combination is exactly the pain.

I just wish everything would at least still support blocking IO as a common denominator, so there's at least a baseline that is known to be possible. 99% of percent of the time I do not need benefits of async, because I write small software for relatively small, but still real use-cases. And using Rust ecosystem was easier just a few years ago than it is now for these use-cases, as blocking Rust was not yet relegated to be a second class citizen, replaced by an immature and fractured async.