You did the math.

Yes, that’s the version I was using. And I was trying it this past February or March, so definitely after the switchover to Plasma 6

Vanilla KDE on desktop, Niri WM+Noctalia shell on laptop. Firstly, because for some reason I cannot get any touchpad gestures to work on KDE, and secondly because the niri paradigm of horizontal tiling is just perfect for a laptop. I tried to use Gnome for a while before landing on Niri, but the lack of configurability and the reliance on extensions for basic functionality drove me nuts.

Oh my god, Krohnkite was so unbelievably buggy for me, it kept fully crashing KDE. I tried to get it to work for like a week, but eventually I just had to give up.

deleted by creator

I’m certainly with you on repairing your own Äktas! Cytiva is useless.

Unfortunately, all these scientific-industrial complex companies love to milk us for every penny. The only scenario I’ve seen open source software is in data processing, not collection. Things like spectral simulation, electron microscopy data processing, etc. Hell, I’ve built and contributed to several of them. Why is this? I think there are a few reasons:

1. IP The big conglomerates buy up any smaller company which competes with them, and are more than happy to blatantly infringe one another’s patents and fight it out in court if they can sell more units. I find it very hard to believe they would even consider respecting the GPL. If a smaller company tries to make open software, the conglomerates will grab their software, ignore the license, and drive them out of business. Also, if you replicate functions of the proprietary software in anything but a cleanroom environment, they are fairly likely to sue you.
2. Money: even if it comes in the instrument “bundle”, the software often carries its own significant fee. This is one more way to nickel and dime you, but it is also a way to fluff out the bundle. The more items are in the bundled price, the less obvious it is that the bundled price is significantly higher than the nominal cost of the instrument.
3. Compute topology: providing an API on the instrument to talk to requires the bulk of the processing (especially the time-sensitve stuff) to be done on the instrument itself, or the exact timing of API requests becomes very important. This makes the API less useful as a general access surface, because very few scientists know how to write very precisely timed software. To do this on-instrument processing requires an additional microcontroller (or more often, because the basic structure of most instruments has not changed since the first version, an archaic CPU). ^[1] The proposition of “spend more money on hardware, to potentially make less money on software” is hard to sell to them.
4. Motivation: It’s just hard to justify to a PI or a funding agency that you’re spending time duplicating the functionality of existing, working software you already have for the sake of opening it up. So, the people who have a good argument for open software are the ones who don’t have access to the proprietary software to work off of, and so are in the worst position to actually do it.

These are the obstacles to open software on proprietary hardware, so I would argue that open hardware enables open software to be practical, and vice versa. And for basic things like the microscopes and bioreactors others have mentioned, that works out well.

However, as I’m sure you know, the components in most instruments can’t exactly be found in a hardware store! So more complex open apparatus has its own challenges, especially the lifetime: when selecting parts, you dont have a contract with the manufacturer, so you have no idea when your components will change slightly, or the product line will be EOL’d by the manufacturer. This could happen while you’re building the first version, but more likely will happen once you publish your open spec. How do you help someone who can’t get an equivalent component?

All of this leads to the status quo: instead of people taking the time to create a reproducible open piece of hardware and software, most home-built instruments are irrelplicable, poorly documented, 1-of-1 creations.

Anyhow, in general I am of course in favor of open hardware and software, but I think its interesting to understand the complex set of factors surrounding them. As a result, I’ve focused a lot of my effort on those data processing packages – if you need one copy of proprietary software to collect the data that’s one thing, but anybody should be able to analyze it after the fact without having to buy that proprietary software. And of course, don’t write your open source software in a proprietary language, people! (ahem ahem, MATLAB)

My first experience with *nix was a professor leading me into a server room though two biometric locks and setting up the config files for a compute cluster faster than I would have been able to open the files.

He was using Vim, and though it took me a while to learn, the sheer speed with which he was able to get us out of that unbelievably noisy server room sold me for life.

Well, I use vim for text edits and nvim+extensions for an IDE. As close to a vim purist as is reasonable. But frankly, it’s the first one you learn to use well.

Soon to be ex-president, hopefully.

Yeah, this is the good argument against rust-coreutils. Caring what programming language your binaries are made with? That’s pretty out there.

Oh my god theres a Yes, Minister episode about this.

In the announcement they say the resolution (2880x1920) was chosen to be used at 2x scaling for that reason.

I dont fully get that? Its not a multiple of 1920x1080, so thats unclear to me.

I was a longtime KDE user, but the lack of reasonable trackpad gestures drove me up the wall on my laptop, so I’ve been using niri+noctalia for the last couple months. It just feels so right, it’s lovely. Still some edge cases, but overall just so good.

AI slop alert

Consider me enlightened! The recontextualization of the statement makes it make a lot more sense. As with many things, being swept into the tech sphere robbed it of meaning. I also think that the sentiment of “the tools used to build something are not the same tools which can effectively dismantle it” is true in many senses, not just in the context of social/politiical/institutional change.

I was confused by the section “How Taking the ‘Master’s Tools’ Seriously Can Serve Enshittification”. It transitions from an argument that

The early internet was structured around the assumptions of its architects: predominantly white, male, Western, educated, and abled

(which is true), then links this group directly to Facebook. While these descriptors apply to both the founders of the internet and the founders of the tech giants, facebook is at least 15 years younger than the foundation of the public internet, and these two groups are both mutually exclusive and ideologically at odds. The author then goes on to use the social harms of big tech to push back against Doctorow’s first stage of enshittification, when the companies are “good”.

I think this is a fundamental misreading of Doctorow. He has spent his career as a free software advocate, and claiming that the first stage of corporate capture of the internet is the ideal would be anathemic to his more general arguments. What he means by “good” here – and he says this frequently in public discussions on enshittification – is that the product does what it says on the box, with no BS. That people are tempted to use it because it allows people to access the internet without coming up against the sharp edges of the technology itself, and that is a reasonable compromise for many people at first, because it allows more people to access the internet.

The article argues that in order to fully represent the experience of all stakeholders, the internet “getting worse” is an incomplete view, and to understand the impacts outside the white, male, etc. perspective, we should use the tools of decolonialism, which would be true if Doctorows project was a thorough sociological analysis of the impacts of technology. But it isn’t, it’s a rallying cry. The goal of his book is to make a coherent narative of the change in experience for consumers of technology over the era of Big Tech, and it does that. This is far from the only case where it leaves out strong tie-ins to other philosophical or sociological concepts, but there is a strength in a focused argument as well.

It’s unsurprising that Doctorow misappropriated Audre Lorde’s words in their meme form, becuase that’s what the book is – an abbreviated, digestible approach to the topic. However, I’m glad that someone made those connections.

Proton is still wine with extra sauce. It’s just that occasionally the sauce tastes bad :)

Ahhh got it. I thought it was a “I know this is inadvisable, but dammit I’m going to do it anyways” type of post :)

You can’t run steam with no compositor whatsoever, but you can use the steam deck’s solution of using their gamescope micro compositor for everything. You should be able to install gamescope and just run gamescope -e {other CLI options} steam (assuming you’re using the native Arch package and not the flatpak).

My experience using gamescope for steam has been very mixed, but I’ve seen a tutorial somewhere on doing exactly this.

Gamescope isn’t necessarily the best option for every game, and having a normal compositor (which, for now, must support XWayland) is just a much more flexible solution.

This may also be possible with something more general like xwayland-satellite, but frankly steam and all its games still run on the X11 protocol, so if you really don’t need a GUI you might be able to install a vanilla X11 instance and hook to that directly. I can’t speak to either of those options directly.

But is this worth it, in a practical sense? No. You have a reasonably powerful system, and the only performance you’d be saving is a few percent of a single core on the CPU, which in your config is absolutely not worth it.

The GNOME platform application is used by flatpaks. Basically, a flatpak can be built against/designed to be used with a specific visual toolkit. To do that, it needs to download specific parts of that toolkit, which is what you’re seeing.

Just FYI, pipx does use a virtual environment behind the scenes. The idea with pipx or uvx is to install a python script as a standalone script.

Most likely an adapter issue, some failure in communicating the possible resolutions through the HDMI/DP conversion.

Can you find a flex io HDMI port on eBay? Just make sure you get the right version of the flex io card. That’s the most “supported” way to deal with ports, but it’s more expensive than a simple adapter cord.