Gnome developer proposes removing the X11 session(theregister.com) |
Gnome developer proposes removing the X11 session(theregister.com) |
> This plan seems to The Reg's FOSS Desk to be strong-arming people into adopting Wayland.
Or, more reasonably, to maintain less code for alternate paths in favor of fixing the issues that lead people to use those alternate paths.
Wayland has bugs. X has bugs. Fixes to one largely don't help users of the other. Every bit of effort spent fixing a bug in X to help the fraction of users still using it is effort that could have gone into fixing the bugs in Wayland that leave people using X in the first place. A project taking a step like this allows it to consolidate those efforts.
In many cases, a large codebase like GNOME will undoubtedly have huge swaths of unmaintained code that doesn't have good test coverage and corresponds to rarely used features of the software. It also becomes a frustrating game of whack-a-mole when attempting to fix bugs in software with inadequate test coverage.
Another infrequently acknowledged point: writing tests isn't simple, it requires you to have thorough understanding of all the moving parts involved. If the current maintainers do not understand the architecture in some obscure corner of the software, then there is a significant upfront cost to expanding existing tests around that code -- time that can be spent improving frequently used parts of the software.
When nobody steps up for maintenance despite welcoming patches and calling for new maintainers, there is simply no reasonable option besides "remove this unmaintained source of bugs that none of the maintainers know how to properly test"
So, instead, the standard tactics are to 1) push people and projects to maintain the old thing for them as long as possible, 2) treat any new technology that doesn't give you free support as a threat, and respond to it with fear, disparaging and attacking the people and projects who are no longer willing to maintain the old thing forever, trying to rally others to pressure them, and 3) disparage and attack technologies that require integration/cooperation between projects, because it raises the bar for the amount of maintenance effort expected.
New projects should decide up front, and document very clearly, whether they're willing to offer substantial amounts of maintenance effort on behalf of older or more niche technologies.
What fraction is that? I thought X still had the larger user share.
That being said, I'm still using Ubuntu 20.04 LTS on my desktop as I prefer stable systems. That way I can put time into the things I'm interested in more. :)
So, as long as it all works nicely by the time I need to change from Ubuntu 20.04, then I likely won't particularly care if it's wayland or X underneath.
You know what? The equivalent of X11 in windows may be full of cruft, technical debt, poorly thought out / "unelegant" design decisions... But it fucking works. I'm sorry, but I have other things to do than dealing with the constant churn of Linux desktop software.
I remember a decade ago when everyone was supposed to switch to pulseaudio, it was the greatest thing since sliced bread, its design was solid and future proof. Migrating from alsa did break everything and was a PITA. And alsa was still there! The fix for many problems was to configure something in the venerable alsamixer. Now apparently we need to migrate to pipewire. All I know is that upgrading broke my rpi4. I don't care about the software, I just want my htpc to play a video with sound when I get back from work. I still had to run alsamixer and flip a few knobs to get it to work again. This is madness.
- O proper screen recording support
- broken screen sharing
- No proper global keyboard shortcut
- No push to talk support
- Their developers are seriously crazy on their design decisions.
- Several problems with multiple screens
It would be one of many in a long line of backward compatibility missteps they continue to make; and would help shore up my reasons for me to recommend other WMs, as well likely encouraging other developers to bring some of GNOME's good stuff elsewhere.
Of course, no one actually wants to do this work because there is a deep-seated intent to salt the earth where X once stood.
Yes, I know that waypipe is a thing, but it needs to be installed on both ends and I haven't seen any mention of non-Linux support either.
Am I misunderstanding what you're saying?
That's kind of the whole point of using X, the primary use case.
If they wanted buy in the logical thing would be to provide a something usable and feature complete with wlroots like library inside of the first 5 years rather than producing something nobody would use, claiming it is usable, and then slowly evolving it towards usability slower than duke nukem forever while continually claiming it's ready to rock until the lie slowly becomes increasingly true.
>If they wanted buy in the logical thing...
I already know that this was poorly handled. If Microsoft or Apple wanted to change rearchitect display servers I can assure you it would not take over 16 years.
currently i run on x11, either directly via startx or via dwm when developing.
i will switch to wayland in an instant if it demonstrably improves any metric i care about.
i continue to monitor the situation and look forward to improvements in either stack and in drivers.
Then we will complain about "embrace and extend" while people try to replace their xdotool scripts and their perfectly working X11 setups.
Too bad for them: we don't care about custom applications, we still aim to just steal users from Windows. And 2024 will be the Year of Linux on the Desktop.
Outside of a very small niche of obscure window manager developers, this isn't true. GNOME and KDE have been trying to get rid of it for decades. The glaring flaws in the API have been known for that long.
>38 years of backwards compatibility and still being able to deliver performance
No, the Xorg server actually lacks backward compatibility with lots of non-standard X11 extensions that for whatever reason were either removed or were never merged upstream. At the time some of those may have been the best way to deliver performance on specific hardware but, like anything, they didn't hold up and were thrown away. It wasn't because an IBM/Redhat or Collabora employee said so. See also https://en.wikipedia.org/wiki/X_Window_System_protocols_and_...
It's funny because it's the opposite.
On Windows, you can install and update the graphics drivers without restarting, and it can ever seamlessly recover from a GPU crash.
On Linux, you need to update the whole kernel, and if the GPU or the driver crashes, you'll kernel panic.
On the compositor side, on Windows you can easily have multimonitor setups with different fractional DPIs, different refresh rates (including variable refresh rate), mix of HDR and SDR, applications without vsync and so on. On linux, even single monitor HDR is unsupported.
GNOME is the DE equivalent of North Korea. It's like hearing about North Korea contemplating removing the right to wear clothes and going, "I left Earth a decade ago, and this is a good reminder of why I haven't come back." :p
X11 will still be supported by sane (desktop) DEs for as long as Linux will still be in use, is my guess. (Just like window minimization and non-rounded corners and system trays and disabling composition and...)
> Now apparently we need to migrate to pipewire.
I don't even think I'm on pipewire. Using Arch, you can run anything you want; no ones forcing you to do anything. ;D
Not if they remove X from gtk+ too. That is the logical next step.
But on an AMD/Nvidia desktop it's unusable because it's buggy as all hell. It's endless glitches in dozens of applications. At first it appears fine and then you get subtle stuff like like letters not appearing in vscode when you type, OBS won't record etc.
> broken screen sharing
Both work perfectly here with pipewire installed. I can do screen recording, and share my screen in video meetings in Firefox.
> No proper global keyboard shortcut
System-wide keyboard shortcuts already work, through the desktop. The ability for an arbitrary application to request a global keybinding is in progress and expected to become available soon.
> No push to talk support
Completely valid; that's the near-future global keybinding support mentioned in the previous point.
> Several problems with multiple screens
Such as? Reported bug URLs?
For the record, there are other known issues with Wayland, and they're being worked on; nobody's claiming Wayland is perfect at this point, just that the solution is to fix it rather than assuming it's doomed because it doesn't do some specific thing.
> A proper refactor of X11 should have been the way to go and there should had been X12 with modern technologies
Wayland is X12; it's designed and endorsed by the folks who worked on X11.
And I believe gnome still has that thing where if the UI lags, the cursor lags.
Windows DWM, WDDM architecture, and anything graphics related on Windows is superior in so many ways. They should have copied that instead of the mess that Wayland is, which was developed in a manner that is typical for so many free software: the developers think they know better than the users about what features they need or don't need
That would make it a spiritual successor, but not X12.
Considering several comments - and PP's original issues - it also sounds like it isn't ready to become a candidate for X12 at this time.
Yeah, in limited ways, the wayland functionality is there. But as soon as you step off the most-popular-path even a teensy bit, it breaks.
I am relying on Teamviewer for remote desktop access because the official RDP support breaks in a different way with every minor release.
Works just fine. I use OBS.
> - broken screen sharing
Never had any trouble with it.
> - No proper global keyboard shortcut
> - No push to talk support
On its way: https://github.com/flatpak/xdg-desktop-portal/pull/711 / https://flatpak.github.io/xdg-desktop-portal/#gdbus-org.free...
> - Several problems with multiple screens
Haven't had any more than on X11, but then again I do use Nvidia hardware on Linux.
I thing all these things work flawlessly in my KDE Wayland session.
By the way no more blinking and sound cut (my sound goes through HDMI) when rearranging screens.
I've been very late to make the switch (I did a few months ago because I always saw blocker issues with the wayland session), but now it is at a point it works better than on X11. I miss raising apps when they are called from another app (like calling Kate from the terminal) but I know this is coming soon.
Once upon a time you'd do multihead on X with discrete screens and your display environment variable would be something like DISPLAY=:0.0 vs. DISPLAY=:0.1 where the last digit after the dot was the screen number. But your X client would then be confined to that screen. In this old manner you could probably have per-screen DPI stuff work somewhat, but you wouldn't be moving windows across physical monitors like we take for granted today.
Having your X clients connect to DISPLAY=:0 and somewhere behind the scenes that X server is putting its windows across physical displays or moving from one to the other seamlessly is basically Magic (look up XINERAMA) that the protocol is largely ignorant of, so the DPI differences among those physical displays are pretty invisible to the random X client.
It's per screen, though ; you can have different Xresources on different screens bound to different monitors, I'm running such configuration just fine. Actually, since most of the software I'm using is GTK-based, my per-monitor DPI configuration tool(s) are a pair of xsettingsd running with different DISPLAY variables, and having different Xft/DPI values (and a few other tweaks, like different font rendering options). I'm running two openbox instances , xfce4-panel and tint2 , and two picom instances to properly support client side decorations. And I'm trying to scrape some time to patch xfwm4 and xfce4-panel to support per-screen processes for both . This way I'm driving 24" 4K as my primary display, for coding/browsing/etc, and 24" 2K as a sidekick for monitoring/documentation/spotify/etc
My .xsession:
xrdb -screen -display :0.0 -merge .Xresources-0.0
xrdb -screen -display :0.1 -merge .Xresources-0.1
nohup /usr/lib64/xfce4/xfconf/xfconfd &
export FREETYPE_PROPERTIES="cff:no-stem-darkening=0 autofitter:no-stem-darkening=0 cff:darkening-parameters=500,500,2000,450,3300,450,4600,200"
export DISPLAY=:0.0
export GDK_SCALE=2
export GDK_DPI_SCALE=0.5
export QT_AUTO_SCREEN_SCALE_FACTOR=0
export QT_SCREEN_SCALE_FACTORS=2
nohup xsettingsd -c ~/.xsettingsd-0.0 -s 0 &
nohup openbox --config-file ~/.config/openbox/rc-0.0.xml &
~/Apps/Picom/picom --vsync --use-ewmh-active-win --no-frame-pacing --backend glx -b
nohup xfce4-panel --display=:0.0 &
nohup /usr/lib64/xfce4/notifyd/xfce4-notifyd &
export FREETYPE_PROPERTIES="cff:no-stem-darkening=0 autofitter:no-stem-darkening=0"
export DISPLAY=:0.1
unset GDK_SCALE
unset GDK_DPI_SCALE
unset QT_SCREEN_SCALE_FACTORS
nohup xsettingsd -c ~/.xsettingsd-0.1 -s 1 &
nohup openbox --config-file ~/.config/openbox/rc-0.1.xml &
~/Apps/Picom/picom --vsync --use-ewmh-active-win --no-frame-pacing --backend glx -b
nohup tint2 &
waitxrandr --setmonitor has entered the chat
wf-recorder will do Wayland screen recording fromtthe she'll. I don't think anyone has bothered to implement Wayland screen recording in ffmpeg yet, maybe ask the ffmpeg mailing list to check if that's on the roadmap yet.
The article reaches the conclusion that the best way to handle the situation is for the display server to provide the dpi primitives and let the client figure out how best to draw to that dpi. But acknowledges that there is a hack where you can make the server present a standard scaled dpi, but the drawing will then be bad. And there is this new-fangled thing called wayland where all it can do is the hack.
The irony is that wayland is infamous for usually making the clients do the work(I am thinking window managers) and X for providing a standard method. Nether of which is true, but it made me chuckle.
While it technically works, you quickly discover the importance of being able to organize windows to different physical displays after the programs are already running / the windows have been created.
Requiring exiting and relaunching things to migrate them to different physical screens gets old fast.
Both are are really bad desktop environments and part of the reason the FOSS desktop never took off. Also they are mostly developed by full time paid employees with zero community involvement. As such they are the small niche.
> The glaring flaws in the API have been known for that long.
X11 has flaws but I wouldn't call them "glaring". They are a nuisance at best. You don't pay for functionality you don't need. Wayland has glaring flaws because it does not provide and standardize functionality that people need. It also has severe technical flaws like implicit sync which makes all your application stutter when one application has high GPU load.
> Xorg server actually lacks backward compatibility with lots of non-standard X11 extensions that for whatever reason were either removed or were never merged upstream.
Great, so there is a regular organic and efficient clean up process happening that keeps the unused or unpopular stuff out of X11. There shouldn't be much "old cruft" around then. If this is the case, why do we need Wayland?
No. Both of them have a good mix of community contributors to do the fun stuff, and paid employees to do the annoying tasks no one wants to do for free. A good project needs both. Are you really suggesting that another desktop is somehow going to spring up and succeed with no paid employees and no business case? If what you're saying is true, wouldn't that have already happened and left GNOME and KDE in the dust long ago?
>You don't pay for functionality you don't need.
You actually do if you're maintaining the X server and protocol.
>Wayland has glaring flaws because it does not provide and standardize functionality that people need.
These can be fixed by extending the protocol, unlike in X11 where the flaws can't be fixed because they're built into the core.
>It also has severe technical flaws like implicit sync which makes all your application stutter when one application has high GPU load.
This is actually a kernel/driver problem. It also happens in X11 if you use a driver with implicit sync.
>Great, so there is a regular organic and efficient clean up process happening that keeps the unused or unpopular stuff out of X11. There shouldn't be much "old cruft" around then. If this is the case, why do we need Wayland?
No that's not what's happening either. Lots of current X11 extensions (such as Big Requests, XC Misc, XFixes, XSync) actually exist only to paper over old cruft in the core protocol that can never be removed. It's possible to remove other extensions from the core and still keep the core intact. When the core X11 protocol itself becomes unused and unpopular (which it is) then it's time to remove the whole thing.
Not just new projects. Existing projects can do with a clearer roadmap in my opinion. "Gnome 48 will drop X11" is easier to communicate than a merge request titled "session: Remove x11 session targets".
Something called Tauthon is still being patched every few months for people who can't let go of Python 2.7, though I don't see many contributors to that fork.
Sorry, no dice. The Python team said for years as the 2 to 3 rollout grew increasingly catastrophic "If you wan't to keep Python 2 all you have to do is maintain it" and then threatened to sue the guy who called their bluff. It was a real low point in free software.
> Something called Tauthon is still being patched every few months for people who can't let go of Python 2.7
I was curious and did a search for Python 2.8 and found:
- https://news.ycombinator.com/item?id=13144713
- https://news.ycombinator.com/item?id=13159144
Clicking on the GitHub repo it seems that in fact the project making unauthorised use of the name “Python 2.8” was the one that ended up changing its name to Tauthon. Neat!
This is simply not true. The only "odinary" programs according to your definition that I am running are a browser and a terminal. All other xclients I'm running go beyond that and can not work with Xwayland or XQuartz. (a quick ´grep "^[x,X]" .bash_history´ reveals xautolock, xbacklight, xbel, xcalib, xcape, xdpyinfo, xdotool, xkill, xmodmap, xrandr, xrdb, xsel, xset)
Reporting the physical size of the monitor is the right answer. Wayland is simply wrong here.
X11 simply isn't built to do this. If you want this to work, then the last 35 years of clients don't do the right thing and still would need to be changed to use a new extension that behaves more like Wayland does it.
xbacklight, xcalib, xcape, xmodmap, xrandr, xset: These are utilities specific to configuring the X server. They're needed on non-X11 window systems.
xbel: I don't know what this is.
xdotool: Some commands will still work. Other commands that require interaction from the window manager might not work, but they won't work on some X11 window managers either.
xrdb, xsel, xkill: These still work, although for obvious reasons they won't affect native Quartz or Wayland applications.
By the way, none of those are ordinary X applications. Notice how none of them actually display any windows or having graphical interactions with the user? You know, that thing that X11 is designed to do? Put windows on the screen?
I see a lot of games, chat apps, text editors, photo apps, office apps. These all will work fine in XWayland and XQuartz. But also, it's relatively easy to get them running on Wayland natively.
I know this because I'm a packager...
Releasing Python 2.8 would definitely confuse people.
Renaming it is more confusing!
Red Hat and other large companies have maintained Python for years after 2.7 died (EOL date was January 1st, 2020). IBM/Red Hat offer Python 2.7 including security fixes and bug fixes until 2024 (https://access.redhat.com/solutions/4455511).
Had he just provided patches to Python 2.7, nobody would've batted an eye. Instead, they created an alternative language that was completely different (https://web.archive.org/web/20161210161837/https://www.nafta...).
Founders and core devs indicated that the name was the only problem (https://github.com/naftaliharris/tauthon/issues/47#issuecomm...) and that even things like the header file names could continue to be named Python because of API compatibility.
You can fork any open source project you like, but you still need to stick follow trademark law. You can't just release Linux 2.7 because you disagree with breaking changes in 3.0 either, but you're free to take the Linux code and release Twonux if you really care.
> Python 2.8 is a backwards-compatible Python interpreter that runs Python 2 code and C-extensions exactly as-is, while also allowing Python 2 programmers to use the most exciting new language features from Python 3.
Really sounds like Python 2.8 to me!
That's the problem, isn't it? Nobody who works on Python actually worked on this fork, but it sounds and looks official. That's why the Python Foundation people found this troublesome enough to demand a rename.
Tauthnon has lots of additions to normal Python, most stemming from a bunch of PEPs that author liked. You can't run Tauthon code on any Python interpreter (either 2.7 or 3.x), and there are a few edge case incompatibilities as well. It's probably a great interpreter for those who want newer features but are still stuck with Python 2.7 for whatever reason.
X11 didn't have what we currently consider "basic functionality" for decades after its release.
The design of X11 says that every application connected to your display is completely trusted, hence why it can grab any key (and thus be a keylogger if it wants to be). The design of Wayland starts with the premise that every application connecting to your display might not be completely trusted, and thus has to ask for a global key shortcut. That makes some things harder, requiring the design of a protocol for such requests. It also makes it possible to have sandboxed applications. That seems like a tradeoff worth making.
What a strange premise... Do the wayland people have keylocks on all the rooms, drawers and cupboards on their houses?
Unix programs by default have access to all files in the user home. That's the main point of running programs after all: to edit your files. Letting these programs see all pixels in you screen does not seem that bad, does it?
If for some reason you want to run an untrusted application, use a container. But building your whole house around the "untrusted" premise sounds ridiculous.
I guess we should do away with memory protection as well. Filesystem permissions? Bah, they can go too, after all, a computer is generally used by a single person right?
The reality is that many users use untrusted applications that don't have access to home, ergo Flatpak. There are plenty of reasons why the free for all security model for X11 isn't suitable. Besides, that ship has well and truly sailed - most of the X11 devs have been working on Wayland for the better part of a decade now.
What's the relevance of this? You're position is that we should give up features we have for software that doesn't have them after 15 years of knowing they needed them.
For instance, I would argue that "basic functionality" today, established by browsers and phones more than 15 years ago, is the ability to sandbox applications and not treat them as all-powerful. X still doesn't have that today. Wayland had that as a basic design premise from the beginning.
He literally took over an abandoned codebase, and got sued for calling it the codebase's name.
I'd like to see this quantified. How many people using flatpack are afraid of their application reading their files, vs using flatpack simply because it's a convenient way to install programs? I don't mean "oh me me!" responses, are there any user surveys to support the premise that average users are afraid of their applications?
Quite frankly I don't believe this level of paranoia is the norm. On Windows and MacOS, applications installed in the normal way can read the files on your desktop. This is the way it as always been on Linux too, with few exceptions. Letting the most paranoid users set the norms is a recipe for irrelevance. How popular is Qubes? It's a pain in the ass.
https://developer.apple.com/documentation/xcode/configuring-...
Show me where it says a program installed from the MacOS appstore will be unable to read the user's files unless the user explicitly authorizes it. Here's how it actually works as far as I can determine: The application developer grants their app the entitlements to read user files. The user may see that entitlement before installing the application, but thinks nothing of it because of course the program operates on their files. This does not protect the user against a malicious program being shipped with those entitlements and a plausible pretext to justify it. Example: The user downloads a program to read some kind of unusual file for work, the program grants itself access to ~/Downloads because of course it needs that, then the program instead reads ~/Downloads/your-tax-documents
This system only protects the user if the application was legitimate, refrained from granting itself the relevant entitlements, then got compromised by an attacker.
My Linux Desktop runs Chromium, xterm, IntelliJ and occasionally Gimp.
Do I need the Wayland security model? Hardly so.
Am I an outlier among Linux Desktop users? Hardly so.
But anyway, any solution that tells users to only use a small subset of compatible clients is about as disruptive as just switching wholesale to Wayland. It's not the reason anyone is hanging on to the X server.
1. XCB is a low level binding to the X11 protocol. It doesn't really replace Xlib. Originally that was the intention, but it's non-trivial to take an Xlib program and port it to XCB.
2. XCB doesn't know anything about scaling or even about XRandR, besides the wire protocol. Just because a client uses XCB is no guarantee that it even uses XRandR. It's definitely not a guarantee that it implements scaling.
3. There is no way to use XRandR correctly to allow multiple pitches, because XRandR doesn't have that functionality. All it does is report an estimated size of the monitor.
4. The scaling you're talking about is happening in the client, not in XCB or XRandR, and if it's ever going to work at all it needs to be controlled by some other setting or environment variable. Someone else in the thread posted a big set of those environment variables. Ideally you wouldn't use XRandR at all, there would be another extension.
5. None of the above applies to Qt, because Qt is a toolkit that does (mostly) implement the scaling for you. That's why it was weird you grouped it with XCB.
That is the standard way. An app that has its own custom installer or patcher/updater is by definition, using a non-standard install procedure.
But even if it wasn't, it definitely is the standard on Linux, where package managers are the norm.
>The application developer grants their app the entitlements to read user files.
Flatpak works in exactly the same way.
https://xcb.freedesktop.org/manual/group__XCB__RandR__API.ht...
But, yes, software using Xcb does have to actually do it correctly for it to work, like nearly all aspects of software development.
>But, yes, software using Xcb does have to actually do it correctly for it to work,
There isn't a way to do this correctly, it's a hack. The difference is that Qt attempts to do it automatically, compared to XCB that intentionally does nothing for the programmer because it's a low-level binding.
Hacks are often the correct way to do things.
JFC this is annoying. I'm telling you "it works for my professional use case on X11 and doesn't on Wayland" and you keep trying to gaslight me about this by saying it's impossible.
This doesn't work on Wayland. It does work on X11. You can stomp your feet until you're blue in the face but that won't change this basic fact.
If (for whatever reason; I'm still mystified why you care about this) you really really think it's important to get me to switch display servers, make it work on Wayland. Otherwise just let me have my preferences which I largely maintain and package.
In this case, it's not the correct way.
>I'm telling you "it works for my professional use case on X11 and doesn't on Wayland" and you keep trying to gaslight me about this by saying it's impossible.
No it's actually the other way around. You keep gaslighting and insisting that it's a valid solution because it works for a small subset of clients that you've picked for yourself. I'm telling you this isn't a valid solution for any X11 maintainer to put in place. I've already showed you where an X11 maintainer actually said this, but for some reason you think you know better. Well I'm sorry, but it's not a solution. When you maintain something like that, you don't get to pick and choose the clients you support. You have to support all of them. And yes, it is impossible for X11 maintainers to go and find and fix bugs in every single client from the last 35 years or port them all to XCB and rewrite the drawing code or whatever it is you'd like them to do.
>This doesn't work on Wayland. It does work on X11.
No, it doesn't work on X11 either. Refer back to the merge request I posted earlier. This isn't something you can just hack in. Your solution will break down if you ever need to use a different type of client.
>If (for whatever reason; I'm still mystified why you care about this) you really really think it's important to get me to switch display servers, make it work on Wayland. Otherwise just let me have my preferences which I largely maintain and package.
Where is this coming from? I've never said you should switch display servers. I'm only observing that you probably will once the limitations in your approach become apparent. You realistically don't get to even have preferences here, maintaining all of this is too much work for one person. Maybe you won't switch to Wayland, maybe it'll be something else entirely. Who knows? The point is, X11 doesn't do it.
And this is really my problem with talking about open source on HN. The well has been poisoned, I can't point out broken stuff without someone accusing me of having some kind of agenda. As if anyone who's developed for X11 for the last 36 years hasn't run into all these problems, repeatedly. Nothing is going to get fixed if everyone gets defensive and starts playing the blame game when bugs are pointed out. But that's all that happens here. If you ask me, it's yet another sign that the project is finished.