rootnod3

There very much is that boundary. Jira by tech itself is a good product, but now try shoving it down people’s throats and see how that goes.

Or on a bigger scale look at FB/Social media and society. There definitely without a doubt is a boundary. They interact and overlap.

That is the opposite of good. If only big companies can afford bespoke hardware, they literally become a monopoly, At home LLMs and other usages become either prohibitively expensive in purchase and running cost or you have to deal with a low quality model. Just admit that it's environmentally fucked and not open in any sense. This is not something that the community at large should strive for.

And if someone only learns coding from LLMs do you truly believe that they understand the code they are working with? I highly doubt that.

And the experience comes from actually stepping through a debugger, from doing research and not the next best hallucination that some LLM cooked up. They can't even properly construct some CLI arguments and just make up flags that aren't even in the manpage.

Companies are short sighted then. I'd rather build up a good engineer and spent time on it than just sitting them down in front of a LLM.

Problem is that the "good" developers have built up a lot of experience prior to LLMs and therefore can distinguish good from bad code and know the limitations. But if everyone is supposed to use and embrace AI, how will new developers build up this intuition?

You could send a good amount of small probes and make them become the big antenna dish basically. As long as you cover the bases, you can have layers of "big antenna dishes" in onion layers.

So did Ubuntu or Debian. But I am talking nowadays.

And yes, back then I wasn't using OpenBSD.

On the other hand though, updates on OpenBSD are the most painless updates I have ever done. I am more concerned about it's usage of UFS instead of something more robust for drives.

I mean, I definitely love that OpenBSD is the "reference" implementation of PF, but the network performance definitely lacks a bit and UFS is quite outdated and prone to errors on outages. ZFS has the upper hand there and FreeBSD's network performance.

And adjusting from the reference PF to the minor differences on FreeBSD's version is not too bad.

I agree, FreeBSD + PF is a damn good combo.

I'd say not important, but in a way important to be able to do it without, just in case.

Think of old Borland "IDEs", people used to code in only yellow text with no syntax highlighting. Sometimes the slowing down is beneficial.

Sure, having completion and tree sitter highlighting is a very comfy thing to have, but sometimes not having them is a nice exercise.

Joke's on you, I don't use intellisense.

Claude Meat? Meat Code? Copyright is pending

But what will all the vibe coders do then? Trying to use the atrophied brain cells and god forbid try to…brain code?

72Wh + 24Wh battery (one swappable one internal) and running FreeBSD Current.

Sorry, thought I had posted, but didn't get through. It's a T480 with the 72Wh and the 24Wh battery running on FreeBSD. Screen has also been replaced with a low power usage screen which helps a lot in saving battery while still giving good brightness.

Most of the time I am running StumpWM with Emacs on one workspace and Nyxt in another. So just browsing and coding mostly.

OpenBSD gets close, but FreeBSD got a slight edge battery wise. To be fair, that is on an old CPU that still has homogenous cores. More modern CPUs can probably benefit from a more heterogenous scheduler.

Maybe because there are many different set theories. The one taught in school is not a correct one but grokable for most students. Then you got the Zermeno Frenkel set theory, and you got the Homotopy Type Theory one which can yield or emulate the same results. So in a sense the opening statement is correct. There is no consensus on a single "this is THE one and true correct set theory"

I run an old T480 with FreeBSD and get about 17 hours of battery out of it. Sure, it’s a bit thicker but gets the job done as a daily driver.

In daily practice you don't. Unless you host in a DC with lots of spam. Use small but trusted hosters.

But as long as you get SSL/DKIM/SPF and the other stuff right, and it's not THAT difficult, then most hosters will let you through. Unless it's German Telecom, because for some reason t-online.de decided to only allow emails from hosters they whitelisted and there's a whole approval process which even requires registering with them with an email that is NOT from your domain and even a fax, but honestly fuck anyone using that domain.

Honestly, get a small VM at openbsd.amsterdam or another good hoster and just do it yourself. OpenBSD has outstanding documentation, standing up SMTPD and Dovecot there is super simple, especially for a single user and not a whole group or family (where LDAP or Kerberos would be warranted). Just take initiative and own your data. Does it cost a little bit upfront time? Sure, but maybe just weekend. Does it require a little maintenance here and there? Sure. But still cheaper than paying for fastmail or waiting for fastmail to also exploit your data because the shareholders said so....just own your data.

Alright, I see that line, but in what sense is that bad journalism? I could in the same vein call this out as a bad comment.

One could use encryption but most receiving users have not the faintest clue on how to use that. If most people would care, then I wouldn't give a flying fuck about what Google does because they can't read my mail even if they wanted to.

Sorry, but that "doomsday" "alarmism" is exactly what is needed and warranted. But this practice of sneakily opting users in into things they don't want instead of a very clear full on pop up saying "We now use your data and private emails for AI training" is exactly the problem.

> I know that Google does a lot of bad stuff but we don’t need to make up stuff they just aren’t doing

No no. a) they ARE doing a lot of bad stuff and b) that shit ain't made up and they ARE exactly doing that. Or do you also think that Github is NOT using priI know that Google does a lot of bad stuff but we don’t need to make up stuff they just aren’t doingvate repos to train Copilot? Do you honestly and truly believe that?

If you do truly believe that I got a bunch of bridges to sell to you.

Of course zones and jails win a bit there, because they get their own native networking stack on the kernel instead of going through bridges.

Not much experience with Solaris zones, but FreeBSD jails and their vnets are amazingly good. They also don't lose much in translation. Say you run an Ubuntu 12.04 with a Debian 13 Docker image. Sure, it works, but it has to translate.

Jails have the restriction that a jail can't have a higher version than the host system. So there's (almost) zero translation involved.

My home stack is OpenBSD for the gateway/router, several FreeBSD machines (services, DBs, pkg build server, data storage/NAS) and another OpenBSD machine to run OpenBSD VMs via VMD and I haven't looked back since then. It's a stack that works with impeccable perfomance and equally impeccable documentation. Should the internet crumble due to another AWS us-east-1 or another cloudflare fuckup I can at least run my local stuff and feel confident enough to continue making changes to the system just based off the locally available documentation.

Then at least I'd pick something as a project that you are interested in. Think of your favorite Clojure library and do it in Rust. Or think of specific Clojure features that you would love to use in Rust and get cracking on a library.

Or find an existing Rust project and start contributing. JuJutsu for example.

Honestly, if you have little interest in the language, then why do it? If it's to see if you might actually like it, pick anything, get a feel for it. Or do it in a language you actually have interest in.

Why subject yourself to a language you have no interest in just to gain clout?

As if the language models currently would give a damn about copyright...

Yes, but I also think that the BSDs are the last bastions you will find any AI usage in. And I for one am grateful for that.

I like it when my system comes with a complete set of manpages and good docs.

But you mentioned Flox, which I didn't even know about. First I thought that's what they renamed the Nix fork to after the schism, but now I see it's a paid product and yuck...just further deepens my believe in going more bare bones manual control, even if sometimes bothersome.

> What if there's no room in the workspaces that need Gimp? Or what if you only want Gimp occasionally, so you don't want it to fight for layout with your important windows in each workspace.

If I can't be bothered to use another workspace for Gimp, then I'll open it as a stacked window in StumpWM. So no fighting over space.

If you seriously end up with 5+ GIMP instances and 5+ projects, then I have to say: there is no way you work on that many projects at once. If you do, then that sounds more like a workflow problem.

I usually only have one, maybe 2 projects open, and a browser or two somewhere, maybe a terminal if I need a non-Emacs terminal. If you got 3-4-5-6 projects going at the same time that really is a project management problem I'd wager.

Might also be that I just have tabs or "workspaces" in my Emacs.

But I just can't see the advantage of the scrolling to just plain workspaces. The scrolling to me just adds one more indirection of having to remember where something is. It adds a new level to the navigation tree.

We can probably end that then, because you saw MY point. Whatever that means :D

Tried Niri before, but it seemed more to adhere to fancy animations than actual improvements.

I used to love both, Kubernetes and Nix. But after a few years of using both I felt like the abstraction levels are a bit too deep.

Sure, it's easy to stand up a mail server in NixOS, or to just use docker/kubernetes to deploy stuff. But after a few years it felt like I don't have a single understanding of the stack. When shit hits the fan, it makes it very difficult to troubleshoot.

I am now back on running my servers on FreeBSD/OpenBSD and jails or VMM respectively. And also dumbing the stack down to just "run it in a jail, but set it up manually".

The only outlier is Immich. For some reason they only officially support the docker images but not a single clear instruction on how to set it up manually. Sure, I could look at the Dockerfiles, but many of the scripts also expect docker to be present.

And now that FreeBSD also has reproducible builds, it took one more stone away from Nix.

I open Gimp on a scratch workspace and immediately have my WM jump to it. How is that different from having to scroll to it?

If I need a Gimp in every workspace I just open a Gimp in every workspace where I need one. Or even customize my Xmonad to show specific Gimp instances on select workspaces.

Again, how does the scrolling layout do me ANY favors here?

Sure, Niri takes away the question of where to place it, but it definitely doesn't help with "Where the fuck is that one window I opened and how do I find it?" I'd rather just quickly select all my workspaces in the worst case than selecting every workspace and THEN scrolling through all the windows.

If you really need THAT much overspill on a workspace I would personally rather stop and re-evaluate the workflow instead of just spilling tons of windows all over the workspace.

It feels like if you'd sit down and re-evaluate the workflow and the setup, those problems could be solved almost without a WM.

If I an switch left and right via keyboard, why just not switch workspaces? I honestly don't see the point in the scrolling layout.

Switched workspaces I know what is on each workspace, I can switch to it, see what's there. But the Niri approach, I have to scroll through the space to see which windows are actually there.