Javascript is a dogshit language that everyone is stuck with. The best that we can hope for is the likes of typescript take the edge off of it. Even though it’s like smearing marzipan over a turd. At least it’s ok if you don’t take a deep bite.

Depends what you mean by bloat. It has a very large repo, but it compiles into little commands with least privilege execution. A lot of those commands are specifically there so someone doesn’t have to pull in other repos with a larger attack surface. e.g. there is a time sync daemon to replace having to pull in ntp which is a lot more complex and fraught and the one thing most desktops need of NTP which is to set the clock.

Why do you still exist? I try understanding what the purpose of your reply could be? Screenrecords do not work. For plenty of people. Google it. Yet you feel entitled to share you smalldick energy wisdom of “proper way”. That is exactly the vibe of the shit ppl. You do not help Wayland or x11 or anything, you just fap into your own mouth because nobody can ever love you like that. Go get help.

Wow, someone needs to grow up. You laid into Wayland when screen recording doesn’t even go through Wayland. The app asks the WM to screen record via DBus. A more constructive response would have been “thanks I didn’t know that”, or perhaps “oh it’s a driver issue”, or “it’s an issue with that WM/ffmpeg/pipewire or whatever”, or anything else likely to be the underlying cause. But it’s not Wayland. Have you got that? Not Wayland. There is no need to be sore and immature about it.

Screen records do work providing the app asks for a screen cast in the proper way (which BTW is not via Wayland but through a message to a DBus service). The service and the desktop then ask permission from the user if necessary. X11 didn’t give a damn about protecting the contents of your screen and any app whether it was beneficial or malicious could do it with impunity. So you should see this as a major security improvement - you can screen record but only if permission is granted.

Yes it’s been stable for some time with a couple of caveats - you need a decent graphics driver and not be using apps with edge cases.

Here is a simple example of an edge case and it’s not hard to find people blaming Wayland even though with some thought this was a security issue - apps like Zoom, Discord, MS Teams want to do screen sharing which is easy in X11 because it has non existent security - just steal the screen bitmap. That’s a problem.

Wayland (the protocol) provides no means for one app to grab the screen, or other apps. This is by design for security. Instead the app must be a good citizen and send a “i want to screen cast” message to the xdg-desktop-portal (a service provider implemented by GNOME, KDE etc.), the desktop asks for user consent and then the app gets a video stream. So it’s a lot more secure but it requires the app and the WM do things properly.

Desktops and apps have matured and these issues are thankfully going away. I think the biggest hurdle left is proper graphics drivers, especially the problem of getting NVidia drivers working.

I think Wayland just attracts trolls in the same way as systemd does.

I’m glad Wayland is maturing and taking over. Even most of the X11 devs hated X11 which tells you something.

AI is certainly a very handy tool and has helped me out a lot but anybody who thinks “vibe programming” (i.e. programming from ignorance) is a good idea or will save money is woefully misinformed. Hire good programmers, let them use AI if they like, but trust the programmer’s judgement over some AI.

That’s because you NEED that experience to notice the AI is outputting garbage. Otherwise it looks superficially okay but the code is terrible, or fragile, or not even doing what you asked it properly. e.g. if I asked Gemini to generate a web server with Jetty it might output something correct or an unholy mess of Jetty 8, 9, 10, 11, 12 with annotations and/or programmatic styles, or the correct / incorrect pom dependencies.

GTK 3 support just in time for GTK 4 & 5

I’ve been using it on and off since 1994. I still have a slackware dist on CD with the 1.1 kernel. I think Linux is great although I still prefer to use Windows, and Linux via WSL which is my optimal set up these days.

That’s more or less it. Linux Torvalds hates the different package managers and dependencies in different dists and versions of dists. He claims it’s virtually impossible to ship products that just run on some random dist and cites his own sideproject which is a sea diving app where he builds binaries for Mac OSX and Windows but can’t for Linux. He also praises Valve for using containers.

In theory it means slightly larger binaries, but the flipside it means Steam for Linux runs on a lot more dists, and so do the games and it’s far easier to test they actually run.

Ubuntu. There are mixes of it but out of the box Ubuntu is about as straightforward a dist to install as possible and it is well supported.

That said “new laptop” and Linux are not always a match made in heaven. You might try it from a boot stick and confirm that things like the GPU, touch screen, touchpad, fingerprint reader, USB C / Lightning all work properly.

It doesn’t work like that. UTC goes forward always. Leap seconds are scheduled and known in advance. NTP time services will just smear time advancement a little to account for an additional second. Time never has to go backwards. This is how Google does it.

Leap seconds still make time go forwards, not backwards. NTP clients would also resolve small time discrepancies while still advancing forwards prior to the next time sync.

I didn’t say Unix time, I said UTC. And no it won’t report negative time, not unless somehow the system clock was modified while it was running…

UTC always goes forward regardless of the timezone and local time. That is why you should use it. To take my EPG situation above, I stored program start / end times in UTC so they would render properly even if DST kicked in or not during the middle of the program.

Yes as long as the rules are known, but it’s really just better to do things sanely and leave no margin of doubt.

True but so do most computers. Computers have a database of timezones and time offsets around the world. Depending on the UTC date and time, and your current timezone it will look up what offset to apply to show the local time. The database is very gnarly since rules change over time, e.g. maybe in the 70s some countries had longer DST to counteract oil shortages.

I once developed an electronic program guide for a cable TV company in New Zealand and I’d lose my mind if I had to use timezones. The basic rule of thumb was:

a) Internally you use UTC religiously. UTC is the same everywhere on Earth, time always goes forward, most languages have classes that represent instants, durations etc. In addition you make damned sure your server time is correct and UTC.

b) You only deal with timezones when presenting something to a user or taking input from a user

Prior to that I had worked for a US trading company that set all their servers to EST and was receiving trades through the system which expressed time & date ambiguously. Just had to assume everywhere that EST was the default but it was just dumb programming and I bet to this day every piece of code they develop has time bugs.

Rust isn’t really OOP like C#, Java or C++ - it has structs with functions that you could consider an “object” but there is no inheritance. Instead Rust uses traits which are a little bit like interfaces in some languages.

The way the kernel is using Rust at the moment is to produce safe bindings for modules to be written in Rust, i.e. you can create a module in Rust source which will be correctly loaded up, the code is safe by default and will have access to kernel services via bindings. I expect over time that more of the kernel will become Rust, but the biggest impediment right now is Rust relies on LLVM and LLVM only supports a subset of targets that a kernel could potentially support with another compiler like gcc.