* Posts by AdamWill

1608 publicly visible posts • joined 4 Nov 2010

Fedora 41's GNOME to go Wayland-only, says goodbye to X.org

AdamWill

Re: Just do it already

There is absolutely nothing anywhere in anything to do with Fedora where we claim to be "a unix-alike OS".

https://www.google.com/search?q=unix+site%253Afedoraproject.org

https://www.google.com/search?q=unix+site%253Afedoraproject.org/docs

https://www.google.com/search?q=unix+site%253Afedoraproject.org/wiki

fedoraproject.org says Fedora is "An innovative platform for hardware, clouds, and containers, built with love by you."

AdamWill

Re: Hardware minimum spec?

Writing that page is pretty difficult anyway because there's so many different...Fedoras. The "minimum spec" for a minimal console install is nothing like the minimum spec for a GNOME desktop install. But you can't really write a five page long doc covering all the options. So...it winds up being a bit of a compromise.

Ubuntu, Kubuntu, openSUSE to get better installation

AdamWill

Re: Non-issue

"Vast majority" is probably a bit of an overstatement. If you have a clean blank drive to use (or one you don't mind getting wiped), great. (really, I mean that: great. This is absolutely how you should install any OS if you possibly can.) Anything else starts to get a bit more complex. Lots of people want to install alongside Windows, or another Linux distribution. Some people have strong opinions about what partition layout they want (imagine that, El Reg readers - people with strong opinions!)

AdamWill

Yes. This is *absolutely* the hardest part.

I think everyone working on installers for every distribution would agree there is no good partitioning interface. Partitioning is a nightmare and nobody knows what the hell a biosboot partition is. All you can do is try to mitigate the pain a bit (or, yes, turn it into a "PICK A DRIVE FOR ME TO EAT WHOLE" operation).

AdamWill

Re: Not mentioned....but should be......

Sure you can. Whether or not we change to the new installer interface in any given release, it has no impact on upgrades, you will be able to upgrade just the same way you have been doing all along. Glad to hear it's been working well for you.

Tesla's Cybertruck may not be so stainless after all

AdamWill

Re: Stainless?

I've got some stainless steel cutlery that goes in the dishwasher all the time too. With rust on it.

ANZ Bank test drives GitHub Copilot – and finds AI does give a helping hand

AdamWill

Yeah. As soon as I read "The bank experiment examined what effect Copilot has on: Developer sentiment and productivity, as well as code quality and security. It required participating software engineers, cloud engineers, and data engineers to tackle six algorithmic coding challenges per week using Python. Those in the control group were not allowed to use Copilot but were allowed to search the internet or use Stack Overflow" I went into full rolleyes mode.

Software engineering is not algorithmic coding challenges. You are proving nothing with "studies" which just involve artificial scenarios that are extremely amenable to LLM training, but of very limited usefulness for your bottom line.

Silicon Valley weirdo's quest to dodge death – yours for $333 a month

AdamWill

Re: Meat

Haven't eaten a sausage in 41 years and counting. Haven't dropped dead yet. Sadly won't be able to let you know if I do, but I'll leave someone my password...

England's village green hydrogen dream in tatters

AdamWill

"It should also be noted that the vast majority of homes in cities in the UK cannot use individual heat pumps due to lack of space and/or noise from the fan units."

Er. Wot?

Have you ever been to literally anywhere in Asia? Or looked at a picture, even? Like this one, in Taipei?

https://www.alamy.com/taipei-taiwan-march-31-2018-the-exterior-of-a-weathered-apartment-building-in-the-city-of-taipei-taiwan-image337579264.html

Those are all heat pumps. If you can dangle hundreds of the things off a high rise building, I think we can work out attaching them to ground-level terraces.

Actually, I live in what is more or less a terrace - a townhouse - in Canada. So I can just tell you. My heat pump sits right outside the front wall, under the front room window. The pipes run up the wall, just like drainpipes. You can barely hear it from two feet away unless it's colder than -10 in winter or hotter than +35 in summer.

Polish train maker denies claims its software bricked rolling stock maintained by competitor

AdamWill

But then *you* have to remember how the monstrosity you created works, too...

Electric vehicles earn shocking report card for reliability

AdamWill

Re: Odd

There's a good theory on this in another story I read on it: this isn't really a story about powertrain technology, it's a story about car manufacturers.

If you look at the overall reliability chart by manufacturer, there are some strong correlations. The most reliable manufacturers do not, yet, make a lot of EVs or even PHEVs. But they *do* make a lot of mild hybrids.

OTOH, the manufacturers that *do* make a lot of EVs and PHEVs seems to be the ones that just just generally suck at making reliable cars.

Or to put it another way: when Toyota et. al. start making more EVs and PHEVs, these results are likely to change.

Come work at HQ... or find a new job, Roblox CEO tells staff

AdamWill

Re: The struggle is real

The struggle is real, indeed, but the fix is not automatically "oh well, everyone work in offices forever".

If you try a new thing, encounter a problem and immediately go back to the old thing, you'll never move forward. Before giving up and going back to the old way, you need to look at ways to fix the problems you ran into. Onboarding is difficult if you just try and make it work exactly the way it worked before, only over Zoom? Okay, then that needs fixing. Fix the documentation! That will help out with much more than just onboarding. It's a perennial problem that nobody sees updating docs as important enough for it to get done - well, now it's more important, right? So get it done. Training videos suck? Well, make better ones. As an old codger (I'm 41, that counts, right?) I firmly believe this generation spends all its time glued to Tiktok and Youtube anyway, so it's not like the concept of "watching videos" is inherently a problem, right? Seems more likely the problem is "the videos suck".

Discussions between multiple employees on video chats are indeed generally terrible - so don't use video chats for casual discussions. Use chat. Again, it's not like people are against group chats, is it? We appear to voluntarily spend hours of our lives hanging out in them. Doesn't seem like doing this at work as well should be an insuperable problem. Heck, maybe some folks would like to use audio chats - chat systems all support those, these days. Both text and audio chat are much better than video chat for casual, unscheduled, and ongoing chatter because the social expectations around them are different: on a video call everybody expects everyone else to be 100% focused on that call, ideally staring at the camera all the time. This isn't how you behave when you're sitting with other people in an office, so it can't replace that experience. Group chats are much *more* like sitting with other people in an office in a lot of ways.

And heck, if you try all that and still find onboarding works better in person - then *do onboarding in person*. This is what my company does even for people who will subsequently work remotely - you go to an office for a week of onboarding that all happens in person, in a cross-functional group. The company can require some more experienced folks from your departments to be there to do the 'folk wisdom' stuff. It's much better to have to take a shift helping out onboarding for a group of new folks every so often than to be expected to be in the office three days a week forever just 'cuz.

I've worked fully remote for nearly 15 years now. It works fine because the work environment is set up to expect and handle this (because folks are very spread out geographically anyhow, even the ones in offices). We use chat systems for casual chatter. We use ticket systems for tracking work. We have in-person onboarding for new folks, and regular conferences for everyone to get in-person energy and the whole "new ideas to work on" thing. There isn't just a binary choice between "everyone comes into the office all the time" and "everyone sits in their house on video calls all the time".

If you get stuck with a company that doesn't want to make an effort to make remote work actually, you know, *work*, that indeed sucks. But it doesn't mean the concept is doomed.

AdamWill

subhead got cut off

"'Zoom fatigue is real,' says bigwig"

I think you missed a bit, there. Here, let me fix it:

"'Zoom fatigue is real,' says bigwig who can afford to live as close as he likes to the office and be chauffeured there every day"

The opinions of his underlings on Zoom fatigue vs. office fatigue were, unsurprisingly, not solicited.

Ubuntu and Fedora clash in beta race, but who wears GNOME better?

AdamWill

hey, good news - as of https://pagure.io/fedora-comps/c/239e52066f0d21ad71d32bdc91e97d33c6e3cdae?branch=main in Fedora 40, you'll see "Camera" not "Cheese".

AdamWill

Filed: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/7063

AdamWill

It would be great if you would ask the GNOME folks for their answers to this rather than guess, because I don't think either of you are actually right, and I know a lot of them. Having been at conferences with them, none of them to my knowledge "live in a terminal window all day, and occasionally switch to a browser, both full-screen".

That's certainly not how I use GNOME. I have two displays, a 13.3" laptop display and a 32" 4K display (both at 125% scaling). On the laptop display I run multiple chat clients (because the world is awful and nobody can agree on one). On the desktop display I typically have Evolution, gedit (yes, gedit, I don't use emacs or vi; the existence of https://wiki.gnome.org/Apps/Builder suggests several GNOME devs don't like to code in them either...), a terminal window and two Firefox windows. I navigate all of this more or less entirely with alt-tab. It works fine.

If you're a window manager nerd I can understand that you wouldn't love GNOME. GNOME isn't that focused on being a window manager. It's attempting to provide a Cohesive Desktop Experience (tm). I appreciate this, so I use it. If you don't, there are plenty of other choices. Frankly I find it pretty weird that people are still mad at GNOME for not still being GNOME 2, especially when there's MATE and Budgie if that's what you want, and Cinnamon if you want a different take on a 'modern' GTK-based desktop. There are choices! Most distros offer you those choices! What's the point in continuing to get mad in comment sections? GNOME 3 came out *twelve and half years ago*. People need to take a lesson from Elsa at some point.

AdamWill

The amount of elision depends on your display size and resolution to some extent. I don't know *why* that's the case, but it does. On my display (32", 4K), "LibreOffice Writer" and "LibreOffice Calc" are fully displayed, for impress I get "LibreOffice Impr..." (which, amusingly, is exactly as many characters as "LibreOffice Impress", sigh). Also note that when you mouse over an item, the full name gets displayed. But it does generally feel like this could be optimized a bit, I'll file some bugs.

GNOME has been trying over time to give apps more sensible display names - in the past this was worse, you didn't get "Image Viewer", you got "Eye of GNOME", for instance, and you got "Totem" instead of "Videos". But it is a bit of an ongoing effort. Cheese is a tool for taking photos or videos from a webcam (you know, say "cheese", har har). To be fair I can't immediately think of a better name that wouldn't get elided to death. :P

AdamWill

beta to final (gnome)

"One thing I found interesting about Fedora 39 beta is that the installer doesn't actually install Gnome 45"

Beta had GNOME 45 Beta. On first update you get GNOME 45.0.

"or any of the other big new versions of packages -- they're all downloaded in that first big update."

probably similar. Beta *does* have pretty new kernel and everything else, but then a lot of it has been bumped to even newer versions since.

GNOME developer proposes removing the X11 session

AdamWill

Re: The sheer f**king arrogance is breathtaking

"Why do these developers insist on removing functionality?"

Because they're the ones doing the work, so they get to decide. It's pretty simple.

"I opted for Cinnamon a few years ago"

Good for you. The Cinnamon devs exercised their ability to choose to make a desktop that's different from GNOME, and you exercised your ability to choose it. So why on earth do you care what the developers of GNOME do? If you looked at a Ford car and a Toyota car and decided you liked the Toyota more, would you then come back years later and yell at Ford for not building a Toyota? Why? What would be the point?

AdamWill

Re: Coming to a fork in the road

Uhhhh...you're aware that Wayland is very much the "classic do-one-thing" approach, and X.org was very much "all-singing all-dancing", right? This is literally the biggest reason the people who develop and maintain *both*, no longer want to develop and maintain X.org.

Unity CEO 'retires' in the wake of fee fiasco

AdamWill

Man, that guy retired so hard, he bounced.

Red Hat bins Bugzilla for RHEL issue tracking, jumps on Jira

AdamWill

Re: Even Microsoft dogfoods things

Even before the gsuite switch we hadn't used that kinda stack for years. We were using Zimbra. I don't know if RH ever used dovecot internally, but if so it's either before my time or before I remember.

AdamWill

Re: All software sucks

"Bugzilla is pretty simplistic - not sure I'd want to run a large, complex project using it."

You wind up using a *lot* of flags...

AdamWill

Re: No suprise.

Nope. Nothing to do with IBM. We've had Jira internally since before the IBM purchase.

AdamWill

Re: No suprise.

Most of it has been on Google for years. (I've been resisting mentioning this in public, but I've seen several folks higher than me in the food chain mention or show it lately, so hey).

I don't like this, but it's not new. RH was never 100% open source internally - you just can't convince finance people or some design folks or various other specialists to ditch the proprietary software they're used to - and over the last decade or so it's been fairly systematically moving off self-hosted software to hosted stuff, which tends to be proprietary. We have Gsuite, Slack (*and* gchat, because just one isn't enough pain!), a proprietary hosted wiki-type thing, Salesforce, Workday, all the same stuff you see everywhere.

There was an ongoing argument about this which basically pitted the benefits to the ecosystem (and product development) of attempting to use self-hosted open source at least where it's viable against the perceived benefits to the bottom line (including liability, which is a growing concern the bigger a company gets - there are a ton of regulatory requirements that affect email and messaging systems, which become increasingly onerous to comply with as a company gets bigger) of just making it all Google's problem, and the Google side won. So, hey. That's life.

Bugzilla is kinda caught between two stools at this point. Developers tend to prefer forge issue trackers because they're simpler and closer to the code. Managers don't think Bugzilla gives them enough whizzy reports and dashboards, which Jira is *great* at. So hey, off the deep end with it! Oh, well.

Red Hat's Mexican standoff: Job cuts? Yes, but we still need someone to boot Linux

AdamWill

Re: "getting patches reviewed and accepted into upstream is painfully slow"

I understand what the OP was referring to, but it's fundamentally incoherent to suggest that we should be "punished" for the RHEL source change by...upstreams refusing to merge changes we are intentionally sending upstream to make them open for everyone to use. It just doesn't make any sense.

You might think it's a common sense requirement, but holy cow, no. The idea that RHEL needed some secret sauce was deeply held at RH for years. One reason Fedora and RHEL have completely different testing processes is that for years it was policy *not* to upstream any RHEL tests to Fedora because it'd be reducing customers' 'incentive' to pay for RHEL. There absolutely were cases where changes were intentionally kept downstream and *not* upstreamed because of the idea this provided some kinda justification for RHEL sales.

Of course, this wasn't the idea of any *engineers*. As you say, nobody wants to actually have the work of maintaining a giant patch set. (Well, waaaaay back in the early 2000s it was kinda more common and could be a kinda badge of pride for distro maintainers, but that mindset went out ages ago). But it wasn't the engineers setting the strategy, of course. If engineers set the strategy the RHEL source change wouldn't have happened (but also, the company would probably have gone broke decades ago, because engineers are terrible at making money.)

Convincing folks that this was wrong and the best thing for everybody is to upstream changes was not a minor effort (which is why it has a catchy name - "upstream first" - and internally it's a whole darn project with documentation and training courses and the whole nine frickin' yards). We're pretty good at it now, but it was absolutely a process to get everybody to buy in. (Not taking the credit for that myself, it wasn't my project.)

AdamWill

Re: "getting patches reviewed and accepted into upstream is painfully slow"

Stop and think about this for a while, and you'll realize it's utterly incoherent.

If we (I work for RH) wanted to be "cagey" with our source, we wouldn't give a flying squirrel whether upstream would merge it, would we? We'd just make all our changes downstream. We're only trying to get them merged upstream *specifically because we're trying not to be 'cagey' about them*! If we were being "cagey" about it, we would specifically *not* want upstreams to merge our changes, would we? Them doing it would be *bad* for us.

Upstream first is a requirement inside RH: major changes go as far upstream as possible, first, before they go downstream. Cases like this, where an upstream is so slow about landing them that we have to maintain a sorta 'fake-upstream' fork to base our packages on, are very rare (I can't think of any besides grub). It's not an RH-specific problem either; other distros also have to carry huge patch sets on grub because of it. Here's Debian's (page 1 of 3!):

https://sources.debian.org/patches/grub2/2.06-13/

Beware cool-looking beta crypto-apps. They may be money-stealing fakes

AdamWill

"Beware cool-looking beta crypto-apps. They may be money-stealing fakes"

...as opposed to inevitably-money-losing genuine ones?

Oracle, SUSE and others caught up in RHEL drama hit back with OpenELA

AdamWill

"withholding"

https://git.centos.org/rpms/bash/tree/c9

https://git.centos.org/rpms/libpng/tree/c9

https://git.centos.org/rpms/vim/tree/c9

https://git.centos.org/rpms/brasero/tree/c9

https://git.centos.org/rpms/gedit/tree/c9

dia isn't in EL 9.

You want to know what RH is doing with those things? There you go. (Also, https://src.fedoraproject.org/rpms/bash , etc).

We would not do anything remotely interesting with any of those things downstream of CentOS Stream. That's not how RHEL development works. If RH is doing anything substantial to an upstream project, it is ideally sent directly to the upstream project. If it's not upstreamable for some reason, or upstream won't merge it, it goes to Fedora. If it can't go to Fedora for some reason - for instance, it's being changed in a RHEL release after it already branched off Fedora, or it's somehow RHEL-specific - it goes to CentOS Stream.

We don't initiate interesting engineering work in RHEL. We just don't. The only things that happen in RHEL that don't happen somewhere upstream first are very, very old backports and embargoed security fixes (we'd *like* to do embargoed security fixes upstream, but it's kinda impossible with how embargoing works).

You won't find special Red Hat secret engineering sauce in the RHEL specs that isn't in the Fedora or CentOS Stream specs. If RH is doing anything interesting to any project you're interested in, you will find that work all the way upstream, or in Fedora, or in CentOS Stream. Anything happening downstream of that is only going to be of interest to people trying to make an exact clone of RHEL, unless for some reason backports of upstream changes to six year old versions float your boat.

RHEL provides value to RHEL customers, and the work that goes into it is expensive, but it's not work that's *interesting* to upstreams.

This is observable in reality, of course. What projects are downstream of RHEL? Nothing but RHEL clones.

HashiCorp's new license is still open source-ish, just with less free lunch

AdamWill

Re: Ah, Open Source

Yes. The thing the OP wanted - "And, in any case, I don't think it is fair to put a blanket change on the code. You want to change license ? Fine. State that, as of YYYY/MM/DD, the last version under Open Source is the current NN.XXX.ZZZZ-WWWW (version numbers are such a hassle these days), and as of version BB.FFFF, the license changes to pay as you go (or whatever)." - is already the case, it can't really be otherwise. They can't retrospectively un-release versions they've already released under an open source license.

Rocky Linux details the loopholes that will help its RHEL rebuild live on

AdamWill

Re: To free or not to free

I didn't intend to present it as positive or negative, just as a statement. The law tends to work that way. either it's legal or it isn't. If our extremely experienced and high-powered F/OSS expert lawyers say it's legal, I'm gonna go with that. Whether you think it's good or bad or something more complicated is a different question and seems to depend a lot on where you're standing and what your values are.

Personally, I wish we didn't feel like we had to do it. It doesn't feel great. But then, I also think it's pretty uncool to rebuild someone else's product and try to make money off it, if they don't want you to do that. As I posted on Mastodon, imagine the same situation with a small project, like davx (a dav sync client I use on Android). It's GPLv3. It's built on top of other F/OSS projects (so I guess the author is 'repackaging other people's work'). The author sells it for $7.50 in the Play Store to try and fund development. It's entirely within the letter and spirit of the GPL for me to take the source, rebrand and rebuild it (maybe as unbreakabledav?), and stick it up in the Play Store for free. Or for $2.50. Would it be cool to do that? I wouldn't feel that great doing it. I dunno. It's complicated.

AdamWill

Re: To free or not to free

As I said, I am not really in a position to argue about that part, and I don't really *want* to. It's going to happen and I guess we'll see how it all shakes out as we go along. I'm not involved in making or implementing any of those decisions (thankfully, because I'd be awful at it). All I know about what it's intended to achieve is, yes, it's intended to make life harder for the clones. How much harder do we want to make it? I don't know. How much harder will it actually make it? I don't know that either.

I really am just interested in talking about RH's F/OSS commitments and contributions overall. I understand that this isn't a win in that column. I just want folks to take a broader view.

My answer to my own question is that I don't think it would be better. I think it's better overall that we do all of our significant development in the open and release it for free, even if we have to do stuff like this to keep the money working out. I'd rather have this than just have us make stuff closed source. In an ideal world we wouldn't have to do this either, but I can't really argue with the folks who actually have to go out and sell this stuff so my salary gets paid. I've heard the stories they have to tell about just how hard the clones make it to do that, and I don't have a *better* idea for solving that. (I'm asking about whether the time delay approach was considered, though).

AdamWill

Re: making them Red Hat customers, at least briefly

y'know, I've somehow not thought to ask why we *didn't* do that. I will now, though...

AdamWill

Re: To free or not to free

I'm not sure your reply has anything to do with my post? I'm not, really, interesting in getting involved deeply in the arguments about whether the RHEL source availability change is good or evil or in the spirit of this or that or the other or the whole red herring about whether rebuilds "have value" (which of course they do, in some sense, Mike kinda misspoke while trying to make a wider point there). What I do want to debate is the idea that not making the RHEL sources publicly available means we've "abandoned open source" (that's one take I've seen quite a lot) or that we're not "sharing our work" as was posited here.

Whatever you think of the merits of the change (I don't really want to argue about it) or the legality of it (I'm not a lawyer, but I trust Richard Fontana when he says he reckons we're golden), I do want to argue that RH is still extremely committed to F/OSS when looked at on a broad scale and not just focusing on the availability of .src.rpms for RHEL. I want to argue that the question of being a good F/OSS citizen has to be a lot broader than RHEL .src.rpm availability.

I think you've gotta keep in mind that we could achieve our goals here in a way that avoids any controversy over the "spirit of the GPL", but probably not a way people would like: we could just go open core. We could find some key but legally-severable-from-the-GPL bit of RHEL and just make it closed source. There, problem solved! Nobody can clone RHEL now, and the GPL has nothing to do with it, since we'd just be...not using the GPL for a bit of software. Just like Gitlab, or Docker, or Apple, or a zillion other software companies that use a lot of F/OSS. We don't do that *because* we actually do want to be as F/OSS-y as we can reasonably be while keeping our business going. We really do want that, believe it or not.

Would that be better for everyone, overall, than our current attempt to keep our business running on a pure F/OSS model?

AdamWill

Re: To free or not to free

Here's the thing: we (I work for RH) *do* "share our added value".

The thing we keep trying to communicate about this change is: if you're actually interested in doing Normal Open Source Stuff with Red Hat, "downstream of RHEL" is the *worst* place to be.

We do not do any significant engineering work in RHEL. One of the internal buzzwords at RH is "upstream first". This means: you do your significant work upstream. All the interesting engineering work we do happens in upstream projects first, then in Fedora, then in Fedora ELN, then in CentOS Stream, then it *finally* trickles down to RHEL.

If you actually want to do normal F/OSS collaboration with RH, you almost certainly don't want or need to be downstream of RHEL. The idea that cutting off the RHEL source means we're not "sharing our work" relies on a misunderstanding of how RH actually *does* work. There is no RH work that would be interesting to most F/OSS developers that's in RHEL and not in anything else. The 'value' of RHEL is not 'it has all this novel stuff in it that you can't find anywhere else'.

The only significant reason that I can think of to be downstream of RHEL is to build a RHEL clone, and the only reason to build a RHEL clone is to not have to pay for RHEL or not have to deal with the subscription stuff. Which, I get it, people like and want! And you *can* argue that it's good for RH to provide/enable free RHEL clones, or that we "ought to" do it because "spirit of GPL" or "we bought CentOS" or whatever. That's up for debate. But I would argue that it's really a *separate* debate. If you want to see and participate in and contribute to and reuse the substantial engineering work RH does, *you already can*, because it all happens upstream of RHEL.

The only stuff that happens in RHEL and nowhere else is *extremely* long-term backports - like, keeping 5+-year-old environments working and patched. Which is hard work, but it's probably not something many people are actually interesting in seeing and collaborating on. Aside from that, embargoed CVE fixes happen first in RHEL, but then land in CentOS Stream (and of course Fedora).

If you take a wider view, I would argue we are significantly *improving* our F/OSS 'accessibility' in recent years. CentOS Stream is not what CentOS used to be, and if you want a RHEL clone it is not the thing you want, but it's much *better* for the 'spirit of open source'. Before CentOS Stream, this is how RHEL was developed:

1. We forked it off Fedora (more or less)

2. Stuff happened in private, behind the Red Hat firewall, where you couldn't see it, for months or years, then a RHEL .0 release appeared, with .src.rpms

Now, this is how RHEL is developed:

1. A new CentOS Stream release forks off Fedora ELN, which is a kind of variant of Fedora with RHEL-like customizations applied, and is entirely open - https://docs.fedoraproject.org/en-US/eln/

2. The new CentOS Stream release itself is fully open, with git repos and everything. All the stuff that used to happen behind the RHEL firewall now happens in public. You can watch the process of the RHEL pre-release and .0 release coming together as it happens. You can submit pull requests, if you like.

Between them, Fedora ELN and CentOS Stream move a *huge* chunk of the RHEL development process from happening in private behind the RH firewall where nobody could see it, to happening in public where everyone can see it and even contribute to it. This, to me, seems like a massive improvement in openness, and it's all happened in the last few years (under the Evil IBM Empire, no less).

Rocky Linux claims to have found 'path forward' from CentOS source purge

AdamWill

b) there is one of two choices. The full context is:

" 3. You may copy and distribute the Program (or a portion or derivative of

it, under Paragraph 2) in object code or executable form under the terms of

Paragraphs 1 and 2 above provided that you also do one of the following:

a) accompany it with the complete corresponding machine-readable

source code, which must be distributed under the terms of

Paragraphs 1 and 2 above; or,

b) accompany it with a written offer, valid for at least three

years, to give any third party free (except for a nominal charge

for the cost of distribution) a complete machine-readable copy of the

corresponding source code, to be distributed under the terms of

Paragraphs 1 and 2 above; or,"

RH complies with this clause by satisfying a), not satisfying b). If RH supplies you with RHEL binaries it also supplies you with the corresponding sources, thus a) is satisfied, which means b) does not have to be satisfied. a) contains no "third party" clause.

Red Hat strikes a crushing blow against RHEL downstreams

AdamWill

Re: I am surprised that IBM took this long

"I suspect this move will also result in a shift way from Red Hat and towards other distributions, e.g. SUSE Linux Enterprise Server and others."

Where are the SLES source RPMs?

Australia to phase out checks by 2030

AdamWill

Re: Don't know what you've lost till it's gone.....

"Call me an old fart, but the less people I have to give my bank details to in order for them to transfer money to me, the more secure I feel."

You don't have to. See article, and the other comment I posted. Any competent banking system can set up a convenient transfer system which only requires a phone number or email address as an identifier, and many already have. (In the US, because Americans are hilarious, their banking system can't do this, so they outsourced this job to new venture-capital-backed companies which charge more money and leak your personal information all over the place, see under Venmo).

"I certainly will not give any humongous corporate entity (gas, 'leccy, etc) the ability to direct debit from my account any amount the want whenever they want. Those companies could not care less about accuracy or what they do. I have friends who have erroneously had thousands of pounds direct debit from their account and then spent months trying to get it back, evenm after they have got companies to admit it was an error."

Use a credit card; you can then challenge any incorrect transaction through your credit card provider.

"The only reason why cheques are being dropped is because the banks and big companies cannot be arsed doing something that takes effort - in a similar way to having real branches. They must save millions per year by closing a branch, yet none of that money comes back to customers."

Well, yeah, of course. They're companies, their job is making money. Being "arsed" to do stuff costs money, and that'd bad. So long as they calculate the number of "old fart"s has declined to a level where servicing them with cheques costs more than they produce in profit, cheques are gonna be gone. Behold, the free market! Innit great.

AdamWill

Re: They still exist?

But as the article notes:

"But the Treasurer and the document he delivered both expressed confidence that Australia will survive the demise of checks – because its New Payments Platform (NPP) improves clearing between financial institutions and allows real-time peer-to-peer payments between accountholders using just an email address or phone number as an identifier."

We have something similar in Canada - https://www.interac.ca/en/consumers/products/interac-e-transfer/ - and it has absolutely taken over. I use it to split restaurant bills, most small service businesses (builders, catsitters, all those kinds of things) prefer it for payments (it costs them much less than credit cards and is much less of a pain than dealing with cheques), and most people use it for buying and selling through craigslist, facebook marketplace etc (much safer than carrying a bunch of cash around). All you need is the recipient's phone number or email address, all the recipient has to do is attach their phone number or email address to their bank account. Transfers usually go through in less than five minutes.

The only time I get cheques any more is for share sales from a US broker. They do offer direct deposits, but they won't deposit in US dollars to my US dollar chequing account (these are common in Canada), they will only deposit in Canadian dollars, meaning they would do the currency conversion at a pretty uncompetitive rate.

Red Hat to stop packaging LibreOffice for RHEL

AdamWill

Re: What about requirements for secure documents?

"But what about information that needs to not only be held securely, but must be *provably* held securely? Such as work by government agencies, law enforcement and legal work where an accusation of unauthorized information disclosure can have serious repercussions whether or the disclosures actually happened."

Nope, even that stuff is getting moved to the cloud.

And there's a plausible argument in favor of it, honestly. If there are 10,000 companies that need secure information storage, it arguably makes more sense for them all to outsource that work to one of a handful of companies that specialize in providing secure information storage, rather than every one of those 10,000 companies coming up with its own system for secure information storage.

This, after all, is why these days in the *physical* world a lot of companies don't keep reams of files in a large physical office any more; if they need to store or safely dispose of physical files, they call Iron Mountain or one of its competitors. Logically speaking it makes more sense for a handful of document storage companies to be good at securely storing/disposing of documents for everyone than for everyone to work out their own document storage/disposal system.

The companies/government bodies just need to be sufficiently convinced that the external company is at least as good as (or preferably better than) they are themselves at doing the work. Given the state of IT at a lot of companies that's probably not a very high bar to clear. This is also exactly why all the cloud companies have been working on security standards compliance and the ability to specify where in the world your data will be stored and all the rest of it.

Asahi Linux developer warns the one true way is Wayland

AdamWill

Are you sure it wasn't in gnome's compositor? We made Wayland the default in fedora 25 (Nov 2016), and I'm pretty sure I was running it for a while before then. I've always used multiple displays. It's long enough that I don't remember exactly when I switched.

AdamWill

Retina does not necessarily imply fractional

"Additionally, the laptop models' displays, as well as Apple's own external screens, are all hi-DPI devices, or as Apple calls them "retina displays". These effectively mandate the use of fractional scaling – something that X.org does not support well."

I don't know if this is from the OA or the author's gloss, but it's not quite right. Retina does not imply *fractional* scaling. In fact, historically it was kinda the opposite. The clever thing about the original Retina displays was that they did *not* require fractional scaling: they only required *integer* scaling, which is a lot easier. (i.e., scale by 2x horizontally and 2x vertically). Apple's bright idea was to just take the laptop's existing display and double its resolution in each direction.

These days, *some* Retina displays are designed to expect fractional (i.e. non-integer) scaling, but definitely not all of them. For instance, per Google, the Macbook Pro 13" has a resolution of 2560x1600, which is 227ppi, which means that 2x integer scaling should give a pretty reasonable display - just like 1280x800 on a 13" screen, only much sharper. That might be a *bit* "lower res" than some people might want, so they might go with 1.75x scaling instead, but 2x would definitely be workable.

The 14" model has a resolution of 3024x1964, 254ppi, which is even more suited to integer scaling - 2x scaling will "look like" 1512x982 , which should be a pretty nice look on a 14" screen.

AdamWill

I've been running multiple monitors on Wayland for, uh, about eight years at this point. It works fine.

Dyson moans about state of UK science and tech, forgets to suck up his own mess

AdamWill

Re: Reporting just as bad as ever in El' Reg...

Unfortunately for *your* narrative, we can do this thing called "comparing", where we look at how Britain's economy has fared compared to how every economy in the EU has fared over the same period. According to New Labour Rishi's argument, Britain should be doing much better, right? Whatever the impact of Russia's invasion, the EU should be just as badly affected, so Britain should still be doing *comparatively* better, what with all the benefits of Brexit.

Only...it's not. It's doing significantly worse, on every conceivable measurable metric.

AdamWill

Re: Reporting just as bad as ever in El' Reg...

So that'll be why wages have increased and the cost of living has declined since Brexit, leading to the greatest increase in Britain's living standards in decades? Wow, how great.

Oh, er, wait *checks notes*, seems that's...not what happened. How strange.

Ubuntu 23.04 welcomes three more flavors, but hamburger menus leave a bad taste

AdamWill

It's called a kebab menu. Yes, really. You're welcome.

Some apps have both - hey, who doesn't like. a bit of variety on the menu? :P

Fed up with Python setup and packaging? Try a shot of Rye

AdamWill

Re: No mention of pip and venv?

I mean, I've never really had *that* much trouble. This is what the packaging/release process for all my Python projects looks like:

https://github.com/os-autoinst/openQA-python-client/blob/main/release.sh

(there are some simpler ways to do the version stuff these days, but that's what I'm used to). Run that script, release is done (published to pypi). I could ditch setup.py and just use pyproject.toml , but that'd maroon far too many older setups, so I keep it around.

Local testing via tox works fine: https://github.com/os-autoinst/openQA-python-client/blob/main/tox.ini (the isolated_build setting for tox makes it not use host system packages, which reduces any chance of different results on different systems), just needs the interpreters for whichever Python versions you want to test installed, which Fedora makes easy. CI just runs tox in containers: https://github.com/os-autoinst/openQA-python-client/blob/main/.github/workflows/tox.yml

However, there's so much noise about this, it must be a real problem for some cases, I've just always had trouble grokking exactly how. I suspect it's partly much more of a problem if you don't develop on Linux (note all the discussion of getting Python installed in the first place, which is never going to be a problem on Linux...), and partly much more of a problem if you don't work in pure Python (so compilation is involved at some point)...

I find Hynek Schlawak a really good source to keep up to date on stuff - https://hynek.me/articles/ .

Lenovo Thinkpad X13s: The stealth Arm-powered laptop

AdamWill

Re: Now hand it to the FOSS desk....

so, uh, I've been holding my breath for this one, and I'm starting to look a bit blue around the gills...

Tupperware looking less airtight than you'd think

AdamWill

Hey, I keep my spare batteries in one.

Ubuntu 23.04 'Lunar Lobster' beta is here in all its glitchy glory

AdamWill

Re: I like Linux but...

If they're shipping snaps out of the box, yeah, that's probably going to add to it. We don't ship flatpaks ootb on Workstation, we do on the immutable Silverblue - I haven't actually compared their base install sizes, it'd be an interesting comparison.