I want to be in the arena. I want to be brave with my life. And when we make the choice to dare greatly, we sign up to get our asses kicked. We can choose courage or we can choose comfort, but we can’t have both. Not at the same time tunnel rush.
FWUPD/LVFS (Linux Vendor Firmware Service) has made it remarkably easy to update a lot of system firmware and device/peripheral firmware under Linux. Prior to widespread LVFS support it was often a daunting chore for Linux users to update device firmware with frequently needing to boot into a Microsoft Windows installation, resorting to FreeDOS for system BIOS updates in the olden days, or go without updating firmware.
My ad blocker turned off at some point and I loaded that link without it… holy shit was that obnoxious. The ads moved things around, blocked the article, autoplayed videos… and that’s what we’re supposed to be appreciative of and turn off our ad blockers for? 🤢
This is what a ton of links end up being. I don’t know how anyone thinks that is an even acceptable user experience. Shit just popping up and covering the actual content. Actual content spread out like you are supposed to search for where the next paragraph is. The current state of most websites is just absolute shit. I end up going in and turning off javascript, since that seems to be the herpes that is behind most of this. I am not sure who or how people are making money off this advertising, but it needs to end (without having to resort to adblockers or disabling javascript). Ads have just absolutely fucked most web browsing and that’s sad.
I 110% agree with you on all points. I have been complaining and telling people about privacy till I am blue in the face, and it just seems like the general public doesn’t care. They just do not care that every second of their life is under surveillance and the data is sold to the highest bidder.
I said this about 2 weeks ago. I was trying to support Phoronix and was browsing on mobile. The site was unusable. They need to get control of that. I have websites and I refuse to ever run ads. Then again, I am not in it for the money.
On the other hand the number of websites that are using ChatGPT to create content, images, and links solely to push ads for profit is getting larger every day. It does not take any effort either. You can pay a monthly fee to have a service auto update your site and the ads are automatic too.
That seems like a very lofty goal, but also sounds pretty great for those affected.
Unrelated, but:
(Rest assured, the non-compete clause in my employment agreement with Microsoft expired long ago.)
Thats a real dick move to lock an accessibility developer into a non-compete clause. If you lose an a11y dev to your competitor, your product wont get worse, the world will better.
For the past two years, I have also been the lead developer of AccessKit
When COSMIC development was officially announced, we mentioned that we would be using AccessKit for accessibility support. While certain people in GNOME were spreading concern and doubts about COSMIC supporting accessibility, work was already underway to integrate AccessKit into COSMIC, successfully.
After the ridiculing of cosmic devs and their ability to do ally, they now realize, “Oh, crap, cosmic is picking up steam. Maybe we should get somewhat serious with accessibility.”
Can’t wait to see gnome continue to flounder here. Best of luck to this new fellow, because I am absolutely sure they will need it. Gnome is afterall, Gnome.
It’s almost like some people don’t represent an entire project’s idea, or almost like people don’t have to double down on their mistakes and can go back on them if they realize it’s better, or almost like the world isn’t a war to see who’s right.
doesn’t change the fact that gnome is still gnome and has been historically hostile to stuff like this, with them taking ages to implement basic things like the wayland idle inhibit protocol. I mean it when I wish them luck because I genuinely think gnome is incapable of making good design decisions.
I found it hard to understand what this is. Overall summary, it’s using new Linux kernel features to make Docker style containers way more efficient
It allows you to compose a bunch of filesystems into one layered stack of read only, at a mount point. It also shares memory between such filesystems and allows layers to be mounted in multiple places
For those familiar with how container images are built, this should make things a faster compared to the overlayfs techniques before. It also enables some kind of new hyper containerized software packages, but I’m not sure if that’s a big deal. Something like how osx mounts a risk image for install or use
Stacks have a performance hit, Docker is also introducing a bunch of experimental features to merge things and whatnot. I just don’t get the entire logic tho.
I am all for hating in GNOME for constantly breaking things. In this case though, are they not moving away from their non-standard system to the JavaScript standard? That seems like something to be supported and, in the long run, it will likely lead to less breakage.
Yes but it would have been nicer to have a transition period in which both methods are supported for a little while so that you don’t literally break every extension in existence up to this release
I will say, as a JavaScript developer, the new module system is a pain everywhere. Node.js went to great pains to allow for an upgrade path without breaking changes, and it’s still a PITA for developers because there are so many edge cases that could go wrong, so you still have to actually keep testing in both older and newer versions.
A hard break like this is painful, but I’m not sure if there’s a better solution. On the upside, it looks like it’ll be easier for someone like me to contribute fixes for this, even if I don’t know the specifics of extension development otherwise.
Extensions that target older GNOME versions will not work in GNOME 45. Likewise, extensions that are adapted to work with GNOME 45 will not work in older versions.
Seriously though, a stable API is not the GTK/GNOME developers' agenda here. Nobody wanting a stable API should write software with this toolkit. That said, if you're a true front end aficionado and you're looking to make your software look awesome every six months, GNOME has got you so covered like the chocolate on a peanut M&M.
For those wanting to write software that won't magically kerslode without yet another recompile (or heavily relying on your distro to do that dirty work) stick with KDE/Qt group. They tend to be less breaky each release.
So basically it’s just another GNOME release gotcha.
AFAIK, the extension developer needs to explicitly set each version of Gnome they support. Even when the Gnome version doesn’t have any breaking changes, the extension developer still needs to update their extension to enable their extension for the new Gnome version.
It makes sense that you have to explicitly verify that it works on every release - even if there had been no intentional breaking changes. That said, if an extension developer would really prefer to YOLO it, they could just pre-emptively add a bunch of future releases.
(Of course, ironically that would’ve broken when they switched to 40.)
It would make more sense to specify something like API versions, not software versions, and flag on the client when it changes without the addon being updated (giving you a choice to run it with a warning or not). That is, unless the version update is specifically flagged as breaking compatibility, in which case it would just warn and not offer to run it anyway until it’s been updated.
Gnome doesn’t really have an extension API and instead the extensions hook directly into Gnome Shell. This allows extensions to do basically anything, but each new Gnome release might break an extension (if the used code path is changed).
I had to orphan a very simple extension I wrote for gnome 3.2-3.10 It was a bugfix that for some reason upstream didn’t even want to acknowledge it existed, and never accepted the patch. So I made the extension, but after about a year of constant breakages I gave up.
That ordeal really made me feel unappreciated as a contributor.
Seriously though, a stable API is not the GTK/GNOME developers’ agenda here. Nobody wanting a stable API should write software with this toolkit.
This blog post doesn’t mention GTK, but I’ve heard GTK will sometimes implement breaking changes in minor version bumps. I was thinking about writing some software with GTK, and I haven’t been deterred so I guess I’ll learn the hard way, but has GTK 4 had any of these stability problems yet?
It’s probably the best scripting language, especially for developers of C-style languages. Python has weird syntax and is slow, Lua is really fast but also has weird syntax. JavaScript looks pretty much like C syntax wise. It’s also possible to use a wide range of existing JavaScript projects to make extension development less burdensome
The JS bindings to GTK4 (GJS) are complete, AFAIK; & allow for facilities like Gtk.Expression which the Python bindings still don’t have — & they’ve made rapid progress in a short time. The online documentation that’s available is also getting really good.
Though I’m not sure why extensions have to be in JS, since JS is acting as a ‘glue language’ to the GObject bindings anyway. Isn’t an extension just a GTK application that talks to specific DBus interfaces?
I suspect that the issue boils down to not-so-well-fleshed-out (to put it politely) dbus interfaces on GTK apps. Probably GJS has an easier time setting/sending messages & signals over DBus, so that’s why extensions are in JS.
Many languages have well functioning bindings to GObject, Gdk, etc.; some are more complete than others (lua’s (lgi) are trailing behind – but still, you can do things like subscribe to a dbus_proxy in an embedded lua that lives inside vim or neovim, and send-receive messages with that) & some even come with good documentation, tutorials, etc.
Yeah! They should have invented their own obscure language for no reason rather than use probably the single most well known programming language on earth!
Um, you’re like more than a decade too late to ask this question. Javascript is pretty much everywhere now, whether you like it or not.
For the record, I dislike it as well - not the language itself mind you, but the fact that they’re using it to make bloated desktop apps and desktop UX. Long gone are the days when devs cared about performance, sometimes going as far as writing code in ASM to get the most out of paltry hardware.
Nowadays, even a $25 computer like the Raspberry Pi has enough computing resources to run bloated JS apps, so no one really cares any more, except for old fogies like us who grew up using entire operating systems that fit on a single floppy disk.
Equally (or more?) impressive is the procedurally generated 3D FPS .kkrieger, which weighed a paltry 96KB. 96KB in 2004 was quite impressive, considering that Doom, released a decade prior, was 2.39 MB, and even the original Wolfenstein 3D, released in '92, was 1MB.
I never claimed that Javascript itself was bloated - it’s about using the right tool for the right job. The bloat comes from using awful frameworks like Electron to create fake “native” apps, and then fooling users into thinking they’re getting a native app, wasting tons CPU resources and sysadmin time trying to fix these bloody Electron apps into shape (speaking as a DevOps guy).
Also, there’s a world of options to chose from for shell programming that strike a better balance between performance and practicality, in the spectrum between ASM and JS. Oh, and writing a modern shell in ASM is most definitely fun, you should give it a try sometime. ASM shells - actually, entire operating exists already, if you aren’t aware of it. You really should check out MenuetOS or KolibriOS sometime. Sure, it’s nothing more than a hobby project, but it’s quite fun to take it for a spin, and experience a preview of how fast and effecient operating systems could be.
Yeah, but not a full-fledged GUI OS with all your basic GUI tools, including a GUI web browser. QNX had a floppy version back that that fit everything - even a bunch of games - on a single 1.44MB floppy.
In saying that, there are modern GUI OSes which you can fit on a floppy, such as MenuetOS and KolibriOS. And because they’re coded fully in assembly, it can actually fit and do a lot more that what QNX-floppy could do back then, which is very impressive for modern code.
The same it does everywhere else. Capitalizing on the sheer number of web devs, and the fact that we get things done without being petty about things we don’t like.
The only real alternative to an embedded scripting language is lua, and too few prefer it over js. Lots of internals in gnome-shell is also written in js, allowing the scripting language to hook straight into the api and data structures without a plugin interface.
In a distant future everything is we assembly, with typed stable interfaces for plugins. But the might happen in gnome 8
See, this is the beauty of running Debian stable as your daily driver. I’ll be on Gnome 43 for two more years, so by the time I upgrade to Gnome 45+ extensions should be compatible. Only half-joking, I really do avoid a lot of early adopter regressions and breakage.
blogs.gnome.org
Hot