e3bc54b2

You are really part of the cream, and I mean it as an honest compliment.

I am part of the dark matter, although self-initiated java upgrades already put me on the right side of bell-curve.

> Also I'd actively remove all apache commons as well. Even in Java8 most of the functionality is redundant.

I used to think that. Then I had to decompress zip files in memory and selectively process the children. Of course Java has the functionality covered in stdlib, but they require so much boilerplate, and commons-compress was such a pleasure that I was done in 10 minutes. The same goes for other apache libs too.

OTOH, I wholeheartedly agree about Lombok being unjustified curse.

> It's a fair point of stuck w/ java8, yet the reference was about "modern java".

And I'm saying that even after writing the most of the first project (closing in on 100kLOC now) in 21, I still can't have records where the make the most sense (service boundaries) because libs and larger ecosystem don't support them.

> Also, if I had 1M LOC and my serialization/communication libraries didn't support whatever I've picked - I'd patch the libraries to support it.

1MLOC in java land is.. not unusual. And if you're talking about patching libs like jackson/jaxb/whatever, my good person, you truly underestimate how much actual work people have (where Java upgrade is a distant afterthought, I only did it because I wanted to scratch the itch and see how far I could push processes in my org), or how much impact that might have for a drive-by contribution. Updating such core ecosystem libs in java is no small feat. They are used absolutely everywhere, and even tiny changes require big testing. There is a reason you find apache libs in every single project, because they have matured over past couple of decades without such drastic rug-pull of a change.

> Records have existed for years

As a fan of Records, this is a punch to the gut.

The ecosystem is years and years away from using records. Almost every huge monolith decade+ project is still on Java 8, those who moved to something new still can't be liberal with them, because oh look, none of the serialize/deserialize libs can work with them because everything, to this day, abuses reflection for generating objects like a giant fucking hack it is.

Apology for the rant, but I migrated a big project to 21 early this year, am in the middle of migrating another 1M+ line codebase to 21, and the sorry state of records is such a sad thing to witness.

I give a decade before records are anything but 'a fancy feature'.

I suppose each kid is its own :)

My niece tends to finish a book start to end within a week or so, hence why I thought of asking. Another reason is I don't get to see her too often, and it is easier to hand over a book a visit, color a page together to get her started, and then she does the rest.

I believe GP meant exploitative towards consumers.

The customer was presented a deal. That the deal includes non-written, ever increasing additional charges unilaterally imposed by other side is exploitative.

Well done! My niece is going to love this!

Is it possible to get all PDFs at once? Hopefully per section? That will really help to print all at once and get her a single book to go on for couple of weeks.

I thought I could do `curl | grep | xargs curl`, but the site returns 520.

Elixir directly uses OTP because it is a dynamically typed language. Gleam folks concluded that OTP isn't really designed with static types in mind, and so set out to build their own version of OTP[0]. It is still early days, and lot of stuff is remaining, but what is already there is pretty good.

[0] https://hexdocs.pm/gleam_otp/

> It seems to have gone off in the direction of "shiny and new"

Ikey's last foray into distro-building also left same impression on me.

> without deeply considering more practical architectural decisions like isolating system vs. userland, configuration management, or manageability

I dunno, FWIW, Solus was very well regarded in UX for a while. It had the best steam integration, and the whole thing felt fairly well thought out for something built and maintained by half dozen people.

> If you're going to create a distro, at least have a use-case justification for it

That is unfair. The developers felt there is a gap between fully imperative state-modifying mudball and fully declarative purity-land, which is true, and decided to try their hand at it. How well they did is yet to be seen.

I was a Solus user back when Ikey left. It was highly unusual, maintainer team had no insight, and frankly as a user it left a fairly bad taste.

But, Ikey had his reasons, and as I've grown up a bit over the years, I realize it is okay. Other maintainers picked up the tab pretty well, and for all its worth, quite a few of those maintainers have joined Ikey on this new distro, which signals a reconciliation.

Combined with other comments, I'd say what happened at Solus was imperfect, could have been communicated better, but probably still couldn't be avoided. Such is life.

The creator is a veteran of both Elixir and Ocaml worlds, and is actively building community around the project too[0]. There are also development streams that are pretty educating[1][2]. As a fan of Erlang runtime, but also wanting static types in my code, I've been trying this out and fairly enjoying so far.

There is also Gleam[3] for static types on BEAM, and as beautiful and simple as the language is, its a bit too barebones and the ecosystem is fairly lacking (as expected of a young language). Ocaml has much better story in both, so I naturally found this more fun.

[0] https://media.ccc.de/v/bob11-2024-erlang-ocaml-same-thing-os...

[1] https://www.youtube.com/@leostera_/videos

[2] https://www.twitch.tv/leostera/

[3] https://gleam.run/

Layoffs almost always mean the few engineers that can do better than more engineers are on the way out, if not via layoffs, then voluntarily.

I recently finally rented a VPS from Hetzner, and to my pleasant surprise was done and ready with my config (shell, utils, services) in under 5 minutes. It took me longer to read about nixos-anywhere and disko in aggregate. NixOS lends itself pretty well to these kinds of magic works.

Similar to sops in a sense that both allow encryption/decryption with SSH keys.

In terms of NixOS integration, both are on equal footing.

I'm just unfond of yaml is all.

Yes and no.

I only need to care about my SSH key(s). Which I had to anyway. But now the secrets for all the services (except SSH) lie right besides their config. Any change in one or other is directly visible in git log.

In short, age cut down on the number and types of secrets that I have to manage out of band. Which is very good. It's always easier to be able to remember 2 things (config + SSH keys) than 2+n things (config + SSH keys + whatever secret mechanism any service uses, times number of services).

Age (and its rust implementation Rage) combined with agenix[0] and age.el[1] has made my self-hosted deployment and management so, so easy without compromising security. That, when combined with general NixOS conveniences is why I'm able to self-host at all. If not for these, just the anxiety of having to setup new server in case of whatever loss and the associated time/opportunity loss kept me from dong the same for years.

Anyway, just want to say that Age is great!

P.S. The author also did an analysis of Restic the backup tool [2] which also prompted me to setup nice backup solution for my machines. Pretty cool.

[0]: https://github.com/ryantm/agenix

[1]: https://github.com/anticomputer/age.el

[2]: https://words.filippo.io/restic-cryptography/

Elixir's type system is still baking(can't define customs types yet), while Gleam's is ready here. Gleam has (familiar to many) battle-tested Hindley-Milner with great type inference, while Elixir's is a different (still sound) set-theoretic one.

But most importantly, Elixir is, and always will be, a gradually typed language. There will always be parts of it that will remain or encourage dynamic typing and that opens the door to ambiguity. In a statically typed language the compiler enforces type annotations and that is where Gleam shines.

I've been writing an mbox parser with gleam and use is really hard to grok for me. I get the use, but in contrast to nearly everything else in the language, it just isn't clearly composable with other stuff. The moment use is introduced, everything below becomes part of it. It is hard for me to express this, but use feels overloaded with its use-cases in real world.

I don't get this point of dirty shit not being illegal in international waters making it legal somehow.

Murdering people is still illegal in international water, we don't see people being boarded for international killing as a service.

Why is shit fuel OK?

> much-maligned aviation sector

It is much maligned because unlike shipping that benefits nearly every single human being and is much more efficient (despite horrible lack of regulations) benefits per person, aviation is used by tiny population and minuscule accomplishments.

That said, shipping does need a heavy global hand to get compliant.

Cars are fair point, and there is serious action being taken by the big Govs to get them pollute less (both China and India have plans to phase out ICEs within next decade).

Gerrit is the gold standard of code reviews and I'll die on that hill. I've heard many a good things about phabricator too, but it requires lot of special tooling while gerrit just uses plain old git semantics.

That said, I live git-pr so far. I have a forgejo instance and I like it for what it provides, but without federation, external contributors aren't able to contribute.

If git-pr can be made to work with forgejo, I'll just go for it (self hosted, of course).

hey, we're in pretty similar place logging wise, and I would really like to know more about your solution. If at all possible, I'd like to understand your rationale and implementation architecture more.

ooh where do I start... Let's see:

1. Every single gradle script is a unique snowflake of mishmashed plugins and custom functions

2. Gradle likes to pretend it is declarative, but as people very quickly learn it really isn't.

3. The one thing a build system is expected to do is be reliable in face of changing platform version, libraries and plugins. But gradle, being built on top a language on top of JDK itself has a Compatibility Matrix[0] that one has to be aware of. Often when upgrading a project you have to update JDK and gradle in explicit order, sometimes multiple times.

4. Speaking of which, did you know that gradle, being designed to build java projects does not even manage multiple JDK versions?!

5. untyped groovy means you're forever left wondering whether what you wrote is actually correct until you run it, at which point it fails with excellent errors that tell you nothing. Granted, this situation has improved in recent days, but a jump from 90th floor compared to 100th is still painful.

6. Every single fkin thing that gradle offers can be done in half dozen ways and nothing tells you which way is better or why. Ex.A: is it providedCompile or implementation? Yes, one is intended to be a replacement for another, and no, they are /not/ same.

7. The 'One Nice Thing' gradle had going for is that it bootstraps itself. But look, if want to add gradle to a 'new' project, you have to install it to your system first and use it to add the wrapper. But after that, you are expected to use the wrapper. Nobody tells you that, you just have to figure it out. Oh and when it comes time to upgrade the wrapper version, you're to use the wrapper itself, not the system gradle, again mentioned nowhere, and if you try updating the wrapper using system gradle, the error helps exactly not.

8. Gradle takes free reign in breaking APIs /between minor versions/. WTF!

9. gradle starts a daemon to cache stuff, which is nice I guess. Except when you don't want it to run a daemon, so you tell it with `--no-daemon`. Do you know what that does? It starts a daemon, runs the build and shuts it down. This may not sound like a big deal, but it is just cherry on top of this shitcacke that tells you just how thoughtfully and well designed gradle is. /s

/endrant

[0]: https://docs.gradle.org/current/userguide/compatibility.html

'Partnership' is another word for collusion, but that is indeed the slippery slope I see here. There's a fine line somewhere and I'm not sure multi-billion dollars of dependency-creating deals are on the right side it.

Besides, partnership implies equality, which, again, I'm not seeing here.

I follow up on valhalla every now and then. It looks few more releases away, probably not before next LTS.

That being said, the amount of rigor with which the JDK devs test their experiments is really something to witness. Its equivalent to old school MS with painstaking maintenance at backwards compatibility, all the while moving the wheel of progress.

Every single change so far has been planned with a decade of advanced planning because that's just how this ecosystem roles.

If I understand correctly, the linked repo is for flox CLI client. While it is welcome, is there a plan to open source the service components? I'd like to deploy flox on my own and have portable environments. Otherwise this I'd just another SaaS with lock-in and "lots of open source love".

hey now, Enum allows trailing comma before semicolon, and ever since discovering that, I've been putting extra comma at the end of last Enum value and semicolon on new line.

Why? Because whenever there's a new value added, git diff shows single line change :)

For better or worse, home-manager is developed outside nixpkgs, where rest of NixOS lies.

While I cannot speak to the reasons behind the schism, home-manager is better thought of as independent project that builds off of abstractions in nixpkgs, without taking into account what NixOS does.

They do. I do, and the interviewer who hired me for current job also did.

Heh, thats pretty cool.

Here in India we just legalized copying for educational purposes. No tricks necessary!

> it will be a rather funny, poignant thing to pass when the earth itself prevents AGI

From one of my favorite all-time comments on HN (https://news.ycombinator.com/item?id=34349582):

> There is a blog called, 'Do the Math' by Tom Murphy. The idea was to take our current energy requires of Earth and extrapolate it at the current 3% year over year growth. I believe it is by the year 3,400 we would use all the energy of the Milky way. The idea was to prove that we cannot grow forever, because in 1,400 years we would somehow use all the energy of a space 100,000 light years across. Good luck with that.

We are still talking about stupidly ridiculously humongous amounts of energy, but the universe itself is a hard limit on energy input. It was real hard punch against my assumptions in life.