Infinity Stones are like Tether (the Cryptocurrency). Whenever they want to make more money, they can just make more of them.

Trump posting “good, I’m glad he’s dead” about Mueller changed my view on this. Before, I would have said celebrating Trump’s death would be encouraging some very problematic tendencies. That “the adult in the room” shouldn’t be driven by spite. Now, I suppose my position is that I don’t really think it’s “wrong” to celebrate his death. By doing so, especially by doing so in his own words, we highlight just how toxic a force he was on the U.S. and on the rest of the world. Celebrating his death may well be one of the better acts of defiance against fascism and authoritarianism one can make. If celebrating Hitler’s death isn’t wrong, perhaps so isn’t celebrating Trump’s.

And yet, would a stabbing victim celebrate the moment the knife is removed from the wound? Surely that time is better spent staunching the bleeding and dressing the wound than rebuking the knife or the stabber.

So, I suppose my answer “I hope with discretion.” I hope to be smart enough to be able to discern when and how to celebrate constructively and when and how is less helpful.

flummoxed by annotations

Not what I said.

People come to me when they can’t make it work because I’m the guy with 20 years experience in Spring.

And Spring MVC runs on top of Servlets. Saying you don’t know enough about Servlets to know whether it’s heavier than Spring or not is like saying you don’t know enough about Javascript to know whether it’s heavier or lighter than jQuery.

You can contribute that way. (Or with money, for instance.) And good on you if you do. (If you contribute in a way that’s actually beneficial, at least. I don’t mean to accuse you or anyone in particular, but of course there are low-effort PRs and such.) But it would be pretty antithetical to the spirit of FOSS to deny you the use of the software or access to the source code if you don’t. Which is part of the beauty.

Honestly, hard disagree. It makes building a skeleton application really quick, but it’s so magical. As the guy who people come to when they’ve been banging their head against a problem (because we bumped the version on one random serialization library and now the org.springframework.core.initializer.GenericSecurityPolicyContextFactoryConfigurationProviderServiceScannerImpl doesn’t work, so we’re faced with days more of Jar hell) for days, I’d much rather we just use Servlets directly without involving Spring at all. (And god help us if we ever attempt to upgrade our Java version.)

Servlets was supposed to make everything easier. It 100% has its warts. (Servlet containers are pretty heavy. JSPs are terrible in every way. One of the things I hate most about it is that there’s no way to render a JSP to a string (for instance, for rendering email bodies) short of making a request back to a dummy endpoint on the same application that only does rendering.) But it’s comparatively very clean and explicit, avoids 100 layers of magic, keeps your list of dependencies small, it’s very obvious how you’d do any particular thing with it, etc.

But people decided it wasn’t good enough and built Spring on top of Servlets to supposedly make things easier. I have to imagine it was built by the sort of people who would “fix” their cracked foundation by adding a new story to their house. If anything isn’t acting right with Spring, you have to understand both Spring and Servlets to be able to fix it. And as I’ve probably mentioned a few times, Spring is suuuuuuper magical. And integrating other third-party things with Spring involves voodoo every time.

And then everything was good! Just kidding. Everybody agreed that wasn’t good enough either. So did they fix Spring? No. They built another story on top of the failing foundation. Spring Boot. Which adds still more layers of magic on top. I’m no fan of XML, but I’d rather deal with a web.xml file than try to figure out what the hell any particular Spring annotation is actually doing (because it isn’t working) any day.

Aside from that, you look for fixes online, and you get a Stack Overflow post with 8 completely different answers and just have to hope one is right. So I’ve learned not to even search for answers on places like Stack Overflow. Typically, I’ll go straight to the Spring source code when people come to me with issues – because they know I’m the only one brave enough to embark on such a spelunking mission. Spring isn’t really intended to be understood. It’s meant for people to throw… let’s say spaghetti… at the wall until something happens to stick.

Bah! You got me on a rant. Lol. I’m not really familiar with any other Java frameworks. But last time I worked in Django, I loved it. It’s not magic and it is intended to be understood deeply. (Hell. I’ve written ORMs in Java inspired by Django’s ORM because it was so understandable and elegant.)

Anyway. In short, my experience with Spring has been exactly the opposite of yours, apparently. I think the context is one of the more innocuous parts of Spring, and I don’t think it’s that much of a concession to use that.

Maybe I hate Spring because I’m the person that people come to when it’s broken, so every time I have to think about it, it’s because there’s some headache that it’s causing. But then again, maybe everyone else on my team would hate Spring too if they didn’t have me to externalize all the issues it causes onto. Lol.

You think they give even one single fuck how much customer satisfaction you have?

Remember how folks used to say “if you’re not paying, you’re the product”? (That, of course, was never actually true. There’s tons of, for instance, FOSS software out there that legitimately has no ulterior motives or strings attached, potentially aside from copyleft obligations that you don’t try to turn FOSS into proprietary software. But it was true to a certain point.)

Well now that’s true even if you are paying. To them you’re just a revenue source to be milked. They don’t care if you’re happy. Switching to a competitor probably won’t help any, because all their competitors probably have similar problems. You might get lucky and find a provider whose issues aren’t as much of an issue for you specifically. But the headache of switching is stressful enough that shopping around may well not be worth it.

#enshittification #latestagecapitalism

I was only saying I was worried it might become mandatory in the future.

But I’m pretty certain my employer will establish a corporate account with Microsoft for Copilot whereby my employer’s employees get the premium Copilot “features” (I use the term loosely) by logging in to Copilot using their employee credentials through some SSO integration between the two companies. And then Microsoft will probably provide usage data on a per-employee basis to my employer.

My employer has a setup almost exactly like this with at least one other SaaS provider. The one I’m thinking of isn’t an LLM provider like Copilot. But my employer has made it clear that a) they’re monitoring usage by employees and b) usage (to the tune of a certain number of hours per week) is mandatory.

I could swear I remember hearing about a variant with rules kindof like that. Vaguely, I remember that the variant involved a rule where as a turn, you could put a piece back on the board. I’m pretty sure it had to be placed on “your half” of the board. Like, you couldn’t just place it right on the square right next to the enemy’s king when the enemy’s king hasn’t even moved yet.

I don’t recall for certain whether it was your previously captured pieces that could be respawned (like, if your rook was captured, you could respawn it) or something more like you could spawn a piece of your enemy’s that you’d previously captured (like, if you’re playing white and you capture a black knight, you could spawn an additional white knight on your side of the board).

And I can’t remember if that variant had any particular name.

As someone who downvoted, yes, what @surewhynotlem said is exactly why I downvoted.

And given that OP is unwilling to elaborate any, this whole thread seems like just a frustrating waste of time.

Timely post for me. My employer has decided to “standardize on Copilot” (after previously telling us to use Gemini but never getting us the wherewithal to actually utilize the corporate Gemini license they’d established; don’t ask me to make it make sense) and it’s possible they’ll soon start requiring us to use Copilot. I expressed to a coworker that "maybe there’s something that’s technically under the “Copilot” brand that is much less invasive and bullshit that we can use so we can say we’re “using Copilot” in a “malicious compliance” kind of way but not actually have to… you know, use an LLM for anything that’s going to fuck up our regular work. Like, maybe I can use the Copilot Outlook integration to send myself emails that I can somewhat plausibly claim to be reminders to myself. Following the letter, but not the spirit, of the “law”. Maybe I can even automate it. Whatever the case, if I was to do such a thing, this graphic could be a useful resource. Though for now, we haven’t yet gotten any mandate to “use Copilot.”

We did something similar years ago. We were told we “had to use Spring” for a Java project we were building from scratch. So we used a tiny little piece of the Spring ecosystem of libraries. The Spring context, mostly. And some of the facilities that would scan for @Configuration classes. (Though we limited the packages it scanned pretty strictly.) Just so we could say “see, we used Spring”. But we used nothing but that. Most notably, we didn’t use Spring controllers or the DispatcherServlet. And even the parts of Spring that we did use, we only let certain portions of our codebase depend on Spring at all, just to limit how much contact our code even had with Spring.

$5 says Trump poisoned him.

Not sure I get what’s up with this.

The license doesn’t appear to be Open Source as far as I’ve skimmed. (Don’t let it being hosted on Github fool you.) I’m not seeing anything about permission to make copies or derivative works, for instance.

It’s not uncommon for AI companies to sneakily try to bill something as Open Source when it’s not.

But also, the post on Hacker News has been flagged and the only comment on that post indicates it may be an April Fools joke. And on top of that, that repo is at over a year old. So in general, I’m kindof confused.

The end of an era.

A phone! That honestly changes everything.

I haven’t really messed with any distros well suited for a touch-screen interface (and no keyboard/mouse)… except Ubuntu Touch. I’ve got it on my Google Pixel 3a.

I’m pretty happy with it. But it’s not like a Linux desktop at all. It’s not really set up to run, say, Libreoffice or Gimp or whatever. I’ve only used the built-in browser and haven’t tried any of the other browsers available, but the built-in one is very “mobile-brower-app-y” rather than anything like a desktop browser… It’s got apps and an app store like Android/iOS has apps and an app store. The ecosystem around it is way more open than either Android or iOS. (Like, you don’t have to register with anyone to side-load things.) And the kernel is Linux, not Android or anything. (There is a way with Waydroid to run Android apps on Ubuntu Touch, but I haven’t tried it.)

There are other Linux-based OSs meant for phones like PostmarketOS, but another thing about the phone distros is that device support is going to be very specific. You’ll want to buy one of the very few devices that is well supported by the distro you want.

So, whether Linux is good for you definitely depends on what you’re wanting more specifically.

Yeah, the ARM situation is pretty impressive now-a-days.

Again, I mostly know about Raspberry Pis (RPi 4’s specifically) and those are mostly pretty low-power/low-CPU-speed kind of devices. And so there are some limitations with regard to just how much “oomph” the Raspberry Pi has. Not because it’s an ARM device rather than an AMD64 device so much as because it’s really cheap (which is both a feature and a bug) and low-power. For example, last time I tried using Chromium, I found it nearly unusable for how slow it ran, but Firefox works great. (Though I do turn off things like smooth scrolling animations and such just to lower how much CPU it uses. It’s still “regular Firefox”, though. Not some “minimal” fork like Fennec or anything.) But again, that’s mostly because the Raspberry Pi is low power, not because it’s ARM. But the Raspberry Pi also has good 3d graphics support, so Luanti runs surprisingly well and very playably. I’m also kindof a terminal-or-die kind of guy, so not using heavy GUI apps isn’t much of a problem for me.

But as to the issues that are specific to the fact it’s ARM rather than AMD64, there are very few now-a-days. Binaries, for instance aren’t portable between ARM and AMD64, of course. Very few application just straight up don’t even run on ARM. (Cura is the only one that comes to mind, and it’s been a long time since I tried it, so that might have changed by now. Cura’s kindof a terrible piece of software, though. Good slicer, but the way they just don’t have any interest in making it cleanly/easily runnable on various systems makes it a huge pain to the point that some Linux distros (Gentoo, for instance) have given up supporting it even on AMD64.) I’ve never tried to run Wine on a Raspberry Pi, but it looks like there are options for doing so, and running x86 and AMD64 applications on it. But basically every feature of your browser (including streaming video and WebGL and stuff) works as expected (again, depending on how powerful your ARM device is). Aside from problems with Arch Linux Arm, whatever distro you settle on will have great support for the apps you’re used to using on AMD64. And you’ll have your choice of DE/WM the same as you do on AMD64. Etc.

Oh, I guess one more caveat I’ll mention. Some of the Raspberry Pi’s RPi-specific hardware tends to change a lot over time. The drivers update and there are new ways of doing things that don’t work quite the way they used to. The main places I’ve seen that happen are in the audio drivers (after one update, the audio didn’t work and I had to go down a bit of a rabbit hole to get that working again), the graphics drivers (a few years ago, they released FOSS graphics drivers for the RPi and that changed some of the options available and such, and the main symptom I’ve seen of that is that documentation may be out-of-date and apply only to the old way the graphics drivers work, so it’s definitely worth making sure you know roughly when changes have taken place and that you’re looking at documentation that applies to the latest), some of the miscellaneous boot parameters (on Raspberry Pis, there’s a /boot/firmware/config.txt file that has a bunch of boot-level kernel options), and GPIO pin access.

Which leads me to something else I didn’t think of until just now. The bootloader, driver options, kernel options, and the installation process tend to work differently for ARM devices. With AMD64, you kindof expect UEFI (possibly with legacy BIOS support) to be the norm. With ARM that’s rarely if ever the case. I don’t know that secure boot is likely to be available for very may ARM devices. Disk encryption isn’t something I’ve gone to the trouble to figure out how you’d do. You don’t use Grub, you use U-Boot, or in cases like the Raspberry Pi, the bootloader is kindof hidden away from you except that as you install it and configure it, the kernel/config/driver files go in the right place on the SD card to make sure the bootloader can find them. And the installation process tends to be “stick an SD card into another computer, DD this disk image onto it, and stick it into the target ARM device”. Depending which distro you’re using, from there it might take you into an interactive installer kind of thing (like with Raspian) or it may be more low-level (like with Arch.) And if you follow the default installation instructions for your distro, you most likely end up with a little less control over things like the partition layout, whether you’re using LVM or BTRFS, etc. If you wanted root- or home-partition encryption, my guess is you might have to take an existing installation disk image, dissect it, and build a custom disk image with certain partitions encrypted out of the result before DD’ing it to the SD card. (Ok, I took a break here to check and see if there are guides on how to do full disk encryption on a Raspberry Pi and there are.)

(Side note. You may have to decide when installing a distro on an ARM machine whether you want the 32-bit ARM distro or the 64-bit ARM distro. If you want to run on an older ARM device that doesn’t support 64-bit ARM, you’ll have to go with the 32-bit ARM distro. If you want to run x86 Windows apps on Wine, it’s definitely recommended to use the 32-bit ARM distro. Otherwise, 64-bit is the way to go.)

Ok. Jeez. This ended up being a long post. That’s about all I can think to say at the moment.

The sentence for 2345:0425:2CA1:0000:0000:0567:5673:23b5 is “How silently the linear strips unsettle the new time beyond new mean where inland overcasts desegregate.” I’m not sure that’s really that much easier to remember than the raw number.

🤔

…

🤔 🤔 🤔

Nope. Still doesn’t make sense.

I wish I could recommend Arch Linux Arm, but it’s really poorly maintained. Literally zero packages available for update for months on end. And no hope of improvement in sight.

My experience is mostly with Raspberry Pis. (I’m typing this on a Raspberry Pi in fact.) I still have a couple of Pis on Arch. And the one I’m on right now is running Raspian. I have plans to migrate them all to Gentoo some day, but I want to build a build server first and I’m currently deep in another project. I’ll get to it eventually.

Raspian is boring and maybe a little simplified and restricted. But it’s fine.