* Posts by AdamWill

1583 publicly visible posts • joined 4 Nov 2010

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


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.)


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!):


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


"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








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


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


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.


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).


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...


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?


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


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


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


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.


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


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


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.


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.


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


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.


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


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


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:


(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


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


Hey, I keep my spare batteries in one.

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


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.


Re: I like Linux but...

"I wonder where it is all going. It's probably worthy of an article on its own - the bloat of Linux today."

Boy, can I tell you some stories.

Here's one place it's going:


you see that gigantic pile of iwlwifi-(blah,blah) files? Intel just loves churning out increasingly ridiculous piles of binary firmwares for its wifi adapters. We have to ship all of them or else your wifi won't work.

I have been told that AMD or NVIDIA or both (I forget) is planning to start doing the same with its graphics cards, only in that case each file won't be ~1MB, they'll be ~20MB. That's going to be fun.

There's a whole boatload of fun to be had once you start trying to unpick "bloat". You can read up on some of it at https://bugzilla.redhat.com/show_bug.cgi?id=2149246 . See the top 20 packages by size on a Fedora Workstation live image: https://bugzilla.redhat.com/show_bug.cgi?id=2149246#c62 . Number one is libreoffice, which is 300MB (uncompressed) on its own. Firefox is 233MB. Distros can't really do much about that except not ship them, which probably wouldn't be too popular. Next is glibc-all-langpacks , which is basically a bunch of translations for core system strings to a zillion languages; you can save that by only installing the languages you want. Next is Java, which is there for LibreOffice. Next is linux-firmware, which is a giant pile of upstream vendor-related pain that we (I) trim obsessively but it's a gradually losing battle. ibus, libpinyin-data and google-noto-sans-cjk-vf-fonts are necessary for seeing and typing CJK (that's Chinese, Japanese, Korean) text, which is, you know, quite important to a lot of folks. llvm-libs is needed by mesa, a core part of the graphics stack - mesa very much wants to be built with llvm/clang, not gcc. cldr-emoji-annotation, well, the kids these days can't live without emojis. mesa-dri-drivers makes the pictures show up on the screen. webkitgtk6.0 and webkit2gtk4.1 are different versions of the same goddamn HTML rendering engine because GNOME hasn't managed to get everything onto the newer version yet (so our live images get Firefox's engine and two versions of webkitgtk. Fun.) Then you've got two bits of the kernel, geolite2-city is...uh, hey! We might be able to get rid of that one. It seems it's only there because ipcalc recommends it. I'll look into that. gnome-user-docs does what it says on the tin, firefox-langpacks is localization for firefox, podman is like docker only better (don't @ me), and python3-libs is kinda important.

so, yeah, we're trying! I am, anyway. sigh.

(still, 19GB does seem like sort of a lot. I haven't checked what the smallest disk you can install Workstation to is lately, but I'm pretty sure it's smaller than that. A Rawhide install I have in a VM here seems to have used up 8.3GB of disk; I know our installer has various pads on the size check, and I bet Ubuntu's does too, so it probably wouldn't let you get away with less than about 10-11GB...)

Intel pours Raptor Lake chips into latest NUC Mini PC line


also htpcs

"In addition to those looking for a desktop PC that doesn’t take up all their desk, the NUC 13 Pro is targeting biz applications such as digital signage, edge computing and IoT. For the latter, the hardware is compatible with Windows 10 IoT Enterprise, as well as various Linux distributions."

They're also pretty commonly used as HTPCs. That what I use them for. ARM SBCs are fine if you're *sure* they have hw support for any video you might play, but you're right out of luck when folks come up with a shiny new video format or profile or whatever and your SBC doesn't have hw playback support for it; the CPU sure ain't gonna handle it. Using a NUC means that's usually not a problem.

Gone in 120 seconds: Tesla Model 3 child's play for hackers


Re: @T. F. M. Reader - Expect updates soon

All the exploits of both Ubuntu (which it looks like they mostly just use as a proxy for "Linux in general" - most of these issues will likely turn out to affect most distros) and Windows were local user privilege escalations, which are of usually limited relevance to appliance-type devices like commercial firewalls.

The ThinkPad X1 Carbon Gen 10 as a Linux laptop


fractional scaling

Hey Mark!

So the deal with fractional scaling - by default in upstream GNOME it's disabled. You have to poke a hidden setting to turn it on. For Wayland it's `gsettings set org.gnome.mutter experimental-features "['scale-monitor-framebuffer']"`. For X11 it's `gsettings set org.gnome.mutter experimental-features "['x11-randr-fractional-scaling']"`. (I guess you could do `gsettings set org.gnome.mutter experimental-features "['scale-monitor-framebuffer', 'x11-randr-fractional-scaling']"` for both). After doing that, and a log out / log in cycle, the options for fractional scaling levels should appear in Displays.

I *think* the same or similar applies on other GNOME-derived desktops but I don't have direct experience there.

Fedora currently follows the GNOME upstream default here. I've read that Ubuntu patches this to enable the fractional scaling settings out of the box. We have a Fedora ticket open at https://pagure.io/fedora-workstation/issue/357 where we're discussing the possibility of enabling them on Fedora. Some of the outstanding known issues are covered there; the biggest one is that when you do fractional scaling on Wayland, non-Wayland-native apps (XWayland apps) can't be scaled 'properly' so they just get blown up and look fuzzy. Native Wayland apps look great, though. I've been using fractional scaling on various systems for years and for me it's fine, but I mostly run Wayland-native apps.


Re: Optional

It's for models Lenovo test and are happy with the Linux support for. There isn't a certification programming as such for Fedora, but we (I'm the Fedora QA team lead) work with them on this effort and it's been a great partnership so far. They are gradually broadening the scope of the project over time, each year a few more models tend to be included.


Re: installed on every machine

Lenovo has been participating in LVFS for years. Firmware updates on Lenovo laptops work just fine on Linux.

Adidas grapples with $1.3B in unsold Yeezy sneakers after breaking up with Kanye West


Re: Maybe, just maybe

You're just now learning about hypebeasts? Welp. Yeah. They're a thing.

Ex-Tweep mocked by Musk for asking if he'd actually been fired


Re: What a Cretin.

you can tickle my epliglottis any day, big boy.


Re: What a Cretin.

"No, you're not an idiot. You're a C***, with a capital C.

Congrats. Your the first person to get that word out of me in 30+ years. I hope they sue you into oblivion."

To be fair, C*** is a really hard word to say. Especially the capital C.

WFH? Google Cloud's offices like a 'ghost town' before new policy



This is such *bizarre* logic. "We paid for an expensive office, therefore we must require people to come and work in it even if they don't need to, so it looks like we didn't waste the money". That's the kind of thinking we're paying these galaxy brain CxOs for? Yikes.

I mean, there's a plausible argument to be made that, for some jobs in some companies, working in the same physical location as other folks doing related jobs improves results, therefore it's reasonable to have a policy that results in employees doing that. Sure. There are counter-arguments to that, things may vary across companies and departments and job functions etc etc, but fundamentally, that's at least a supportable argument. But the quoted argument is...not that, it's just nonsense. If you believe you get better work out of people working in offices, say that. If you don't think you need people to come to the office in order to get good work done, don't require them to come in just so you don't feel like you wasted money on the office! Just reduce it in size instead. Good grief.

Telus source code, staff info for sale on dark web forum


Re: Wait, what?

It's a question of whether the data for sale is actually legit or just made up.

By order of Canonical: Official Ubuntu flavors must stop including Flatpak by default


I mean, for systems like flatpak / snap the idea of "handling file dependencies" is a bit...wrong. On those systems, flatpaks/snaps depend on base images, which are never going to conflict with each other. You can install as many flatpaks and snaps as you like and they will never conflict with each other and will all work fine. The only thing is, you'll get a lot of disk space eaten up by different base images, and maybe a lot of RAM consumed by slightly different versions of the same libraries being loaded by different base images if you run a lot of apps based on different base images concurrently.

There's nothing a third-party tool could really do to "handle" this, because the base image requirement is inherent to the thing being deployed, there's nothing you can do to finesse it, you *need* it.


Re: Wow...

I mean...

"Man, it would really suck if a billion or more users had no choice but to upgrade while they learn how use another distro."

or, you know, they could just install Flatpak.

Look, man, I work *on Fedora* and I think that was an overreaction. All the pearl clutching about this has been great fun to read, honestly (makes a change from the daily Two Minutes Hate of systemd and GNOME around here), but good lord, it's not like they kicked it out of the repos. It is arguably a *bit* harsh to say that no "official Ubuntu" can include it, but I mean, that is the kind of decision distros make all the time. And to be fair, I don't think any Fedora spin includes snap OOTB either.

Musk's view count antics are perfect cover for Twitter's paid API failure


Re: I mean

ssssssshhh. the other part of Musk's genius plan is to pretend that's not a thing, and hope it'll go away. I was helping.


I mean

"Musk's claims Twitter is getting close to breaking even"

Well, technically speaking, those claims are true. If you have no revenue and no costs, you're breaking even. Musk has been tanking revenue while also firing as many people as possible and driving those he hasn't fired to quit, which sure reduces salary costs. He's also come up with the genius plan of not paying any bills, which cuts all the other costs.

So, if he just keeps going on this path, fairly soon Twitter will have no revenue and no costs, and will indeed be breaking even!

Core-JS chief complains open source is broken, no one will pay for it



"Open source does appear to be broken"

People keep observing this. It's been going on for decades. And yet here open source still is, launching spaceships and running just about everything.

It occurs to me that F/OSS climbs a wall of worry in the same way as the stock market does - thoughtful, educated people worry constantly about all the things that will definitely cause it to collapse any second now. On occasion, bad stuff actually happens! And yet in the long run...numbers keep going up.

Enterprise IT giant layoffs happened because 'some CEOs got ahead of their skis'


interesting metaphor

""There are some CEOs who got ahead of their skis," Lovelock said."

Of course, when skiers get ahead of their skis, they fall over painfully. When CEOs get "ahead of their skis", the skis get laid off...

Fedora 38 is finally taking shape


Re: Gnome

Or you could just use a desktop you like and not yell about others?

I like GNOME. But I don't go around saying KDE and other desktops I don't like as much should be consigned to the fiery pits of hell. Why would you do that?

If you're actually interested, the reason windows only have a close button is that GNOME's design considers minimize and maximize buttons, respectively, meaningless and redundant. The idea of "minimizing" a window doesn't make much sense in GNOME's design; it doesn't really do anything useful. You may as well just switch to the other window you want to see and not worry about the window you want to "minimize". If you don't agree, or use other extensions that render the concept of "minimizing" a window useful, you can use extensions to put it back, as Liam said.

As for maximizing - you can maximize a window by double-clicking the title bar, so it seemed redundant to the designers to also have a button for doing it. It's much easier to target "anywhere in the title bar" and double click than it is to target a tiny box and single click.

Maybe you disagree with this. That's great. Up to you. You have choices! But you asked for the reason, that's the reason.

I mean, this whole GNOME-bashing thing is just straight up *weird* at this point. GNOME is one desktop. There are lots of desktops. Fedora and every other distro give you lots of choices. If you don't like GNOME, don't use it. We have a KDE spin, an Xfce spin, an LXQt spin...go nuts. Use whatever you like. But "modern" GNOME has been a thing for nearly 12 years at this point. It is going to keep being the thing it is. No number of weirdly angry Register comments is going to change that. There have been other desktops, including forks of GNOME with different design choices, for just as long. Why on earth are people still posting flames about GNOME in every article that even tangentially mentions it (like this one, whose sole mention of GNOME is a passing note wondering whether 44 will make F38), or even articles that don't mention it at all but are (in the flamer's mind) somehow related to it? How are you *that* mad? 12 years worth of mad that just can't be satisfied by saying to yourself "well, that's not for me, guess I'll use something else"?

This isn't the case for any other desktop. There aren't acres of flames of KDE or LXDE or icewm or whatever out there, even though there are certainly people who don't agree with their design choices. I like GNOME's much better than KDE's but I don't hang out in SUSE threads posting that KDE should be consigned to the fiery pits of hell. It's just so *odd*. Why are y'all *this* mad?

Uncle Sam OKs vaccine that protects honeybees against hive-destroying bacterium


well, that explains it

I was wondering why a bunch of rowdy bees are flying around downtown with tiny "DON'T TREAD ON MY HIVE" signs!

Corporate execs: Get back, get back, to the office where you once belonged


Oh good, more dumb absolute takes

Man, I really hate absolutist takes on this question. Like this one from the article: ""How do we get them working on things together? I mean, remote is great, but when you have new and difficult problems, putting people inside of rooms is absolutely critical," he added."

Well, no. No it isn't. I work on Fedora, which is just the underpinning of an OS that runs half the world, no biggy. We've built *that* thing - and mostly built RHEL, even! - with distributed approaches for decades. Works fine. We solve "new and difficult problems" all the time. Lots of the key people working on both Fedora and RHEL are full time remote (including me) and have been since long before the pandemic.

Does this mean everyone should be remote all the time? No. That'd be a stupid thing to say. Some people like working in the office. Some companies have a working style which does work better with people in offices; it's up to those companies and the people who work in them whether this should be considered a problem or not. But it's equally stupid to imagine that nobody can possibly come up with a way to work on "new and difficult problems" that doesn't involve trying to get everyone physically in the same room at the same time.

If your company doesn't have an effective way for people to work on "new and difficult problems" remotely, you need to recognize that, and then you have some decisions to make. Are all your workers OK with working in the office forever? If so, great. If not, more choices. Do you try and get rid of the workers who don't want to come back to the office and only hire people who will? Or do you change your company's processes so you can work efficiently on "new and difficult problems" without making everyone come into the office? You're the manager. Those are your choices. But if your framing is "the only possible way to do this is to make everyone go to an office", you're wrong, and you're a bad manager.

Windows 11 still not winning the OS popularity contest


Re: Awwwww, poor Microsoft

Yeah, it's not so much that they can't convince people to upgrade, it's that they won't let them.

I'd upgrade the Windows boxes I have lying around here to Windows 11 if they "qualified" for it, but they don't. I don't need convincing, just permission...

Musk: Twitter will have 1 billion monthly users inside 18 months


ah, good old trend analysis

"The world's richest man made public a number of slides at the weekend included in his company talk, in which he claimed new user signups in the seven days to November 16 averaged 2 million per day, up 66 percent year-on-year. Further, he said Twitter had recorded 8 billion user active minutes per day for the seven days to November 15, up 30 percent."

...and it sounds like from there, he decided this means Twitter's on trend for a billion users in 18 months. Oh boy.

As someone pointed out elsewhere, this is a lot like the New York Stock Exchange in September 1929 saying "wow, look at all this activity on our trading floor! Things must be going great!"

...or the captain of the Titanic on April 15 proudly noting just how busy traffic seemed to be on the deck...

Massive energy storage system goes online in UK


Re: it can only take the output of about 15 Dogger Bank turbines

"Looks like you'll need about another 200+"

Great, we'll build another 200+, then. Like we built 200+ power stations. Is there some sort of problem with that?

Aviation regulators push for more automation so flights can be run by a single pilot


don't worry, Boeing's got it sorted

"Boeing Southeast Asia president Alexander Feldman told a Bloomberg business summit in Bangkok last week. "The technology is there for single pilots, it's really about where the regulators and the general public feel comfortable.""

A Boeing president telling us everything's fine? Well, I for one am reassured!

Strong support for Snap and Ubuntu Core as Canonical meet IRL


It's a competition. This is an Ubuntu conference, Snaps are tightly associated with Ubuntu, so of course the line pushed will be that Snaps are totally great and everything about them is awesome. You could say Liam could've put a bit more gloss on it, but hey, this is a conference-report article, not a Snaps-vs-Flatpaks article, so fine.

There's lots of between-the-linesing you can do with the article if you know the general 'battle lines', of course. Lots of the lines being pushed here are defences against common points made against Snap in the ongoing debates (the single official app store, the perception of being an Ubuntuverse-only thing, and so on).

If you're not a hardcore fan of either side, I wouldn't honestly worry about it terribly. One or the other will 'win', or they'll just coexist forever, like RPM and DEB, and it won't affect your life much either way.