On Fri, 11 Nov 2022 at 11:30, Peter Humphrey <peter@prh.myzen.co.uk> wrote:
I can't remember any difficulty going from the 5 series to 6.0.0 either, even
though it was a .0 version, which we all know is generally to be suspected.
Not when it comes to the linux kernel though, where major version
changes are arbitrary and comes around the x.19/20/21 switch no matter
which new features are in it.
I can't remember any difficulty going from the 5 series to 6.0.0 either, even though it was a .0 version, which we all know is generally to be suspected.
Howdy,
I been stuck on gentoo-sources 5.14.15 for a while. I tried upgrading
to I think 5.16 and then more recently 5.18. I upgraded like I always
do, copy .config over and run make oldconfig. Once I get everything in /boot, init thingy and all, I update grub. When I get around to
rebooting, the new kernels always fail part way through booting. I
can't recall the error since I last tried a newer kernel several months
ago.
I'm about to try to jump to version 6.0.5 which is latest in the tree.
Is there some major change that causes copying .config file from 5.14 to
5.18 or higher to break? Do I need to configure a new kernel from
scratch in other words? While I try to answer each question the best I
can, either I'm breaking something or something else breaks preventing updating from older versions. I just don't know which it is. Me or it.
I been stuck on gentoo-sources 5.14.15 for a while. I tried upgrading
to I think 5.16 and then more recently 5.18. I upgraded like I always
do, copy .config over and run make oldconfig. Once I get everything in /boot, init thingy and all, I update grub. When I get around to
rebooting, the new kernels always fail part way through booting. I
can't recall the error since I last tried a newer kernel several months
ago.
Is there some major change that causes copying .config file from 5.14 to
5.18 or higher to break?
On Fri, Nov 11, 2022 at 1:25 AM Dale <rdalek1967@gmail.com> wrote:
Is there some major change that causes copying .config file from 5.14 toSo, I just upgraded to 5.15 recently and tend to stick to LTS kernels, precisely to minimize this sort of thing.
5.18 or higher to break?
My guess is that you missed something in make oldconfig, but obviously without exact errors that could be completely wrong.
I can't speak to 6.0 specifically, but one thing that I've found is a
gotcha is when they consolidate config items under higher level ones.
So they'll take what used to be 50 questions, and turn it into 1
question with 50 questions underneath it. The 1 question shows up as
a new config item, and if you don't appreciate what it does and answer
no to it, then you'll disable every item underneath it.
Basically, don't assume that any new question is a new feature, and if
you say no you'll still have all the pre-existing features. It could
be a virtual question and answering no turns off a whole bunch of
things that you had previously said yes to. You need to review
oldconfig questions pretty carefully. You could try defaulting the
answers but even then the defaults aren't always reasonable. They
don't just turn on things you don't need. For example, by default
linux turns off CGROUP support, and almost everything uses that today.
That was just the first thing I checked, and I bet there are a million
other gotchas like that.
--
Rich
Am 11.11.22 um 07:25 schrieb Dale:
I been stuck on gentoo-sources 5.14.15 for a while. I tried upgrading
to I think 5.16 and then more recently 5.18. I upgraded like I always
do, copy .config over and run make oldconfig. Once I get everything in
/boot, init thingy and all, I update grub. When I get around to
rebooting, the new kernels always fail part way through booting. I
can't recall the error since I last tried a newer kernel several months
ago.
Do you follow the guide on gentoo wiki?
https://wiki.gentoo.org/wiki/Kernel/Upgrade
I don't know why but building and installing is not in this article.
For that I do follow this one (there is a link from kernel upgrade to
this on, but it is kind of hidden)
https://wiki.gentoo.org/wiki/Kernel/Configuration#Build
.
...
I did build a new kernel from the old config and running make
oldconfig.
Howdy,
I been stuck on gentoo-sources 5.14.15 for a while. I tried upgrading
to I think 5.16 and then more recently 5.18. I upgraded like I always
do, copy .config over and run make oldconfig. Once I get everything in /boot, init thingy and all, I update grub. When I get around to
rebooting, the new kernels always fail part way through booting. I
can't recall the error since I last tried a newer kernel several months
ago.
I'm about to try to jump to version 6.0.5 which is latest in the tree.
Is there some major change that causes copying .config file from 5.14 to
5.18 or higher to break? Do I need to configure a new kernel from
scratch in other words? While I try to answer each question the best I
can, either I'm breaking something or something else breaks preventing updating from older versions. I just don't know which it is. Me or it.
Howdy,If you've been using 5.14 until now, it would appear to me you're the
I been stuck on gentoo-sources 5.14.15 for a while. I tried upgrading
to I think 5.16 and then more recently 5.18.
On 11/11/2022 08:25, Dale wrote:
Howdy,If you've been using 5.14 until now, it would appear to me you're the
I been stuck on gentoo-sources 5.14.15 for a while. I tried upgrading
to I think 5.16 and then more recently 5.18.
target audience of the LTS kernels. 5.15 is the latest LTS kernel.
Those kernels are maintained with bugfixes and backports for at least
2 years.
The next LTS will probably be 6.1, so if you update to that, stick to
it for the next 2 years and then update to whatever is the latest LTS
then.
Where does one go for a list of the LTS kernels? Since I reboot so
rarely, what not use one of them?? Of course, the kernel I have in use
now has long uptimes so it is sort of LTS for this rig anyway. ;-)
Dale
:-) :-)
><br>> Dale<br>><br>> :-) Â :-) <div><br></div><div><a href="https://www.kernel.org/">https://www.kernel.org/</a><br></div></div>
Where does one go for a list of the LTS kernels? Since I reboot so
rarely, what not use one of them?? Of course, the kernel I have in use
now has long uptimes so it is sort of LTS for this rig anyway.
On 12/11/2022 18:22, Dale wrote:
Where does one go for a list of the LTS kernels? Since I reboot so
rarely, what not use one of them?? Of course, the kernel I have in use
now has long uptimes so it is sort of LTS for this rig anyway.
Do you REALLY want an LTS kernel? Sounds like you don't. You need to
update them just as much as any other kernel.
The point of an LTS kernel is it supposed to NOT receive feature
updates, just bug fixes. Given that Artificial Stupidity bots regularly
try to apply updates to stable kernels, is it worth restricting yourself
 to old kernels? Especially when it's not unknown for a bot to try to backport a patch from kernel X+2, when it depends on a patch from X+1
that hasn't been backported, and anybody using that code finds their
"stable" kernel blowing up in their face.
The idea behind stable kernels is great. The implementation leaves a lot
to be desired and, as always, the reason is not enough manpower.
On 12/11/2022 18:22, Dale wrote:
Where does one go for a list of the LTS kernels? Since I reboot so
rarely, what not use one of them?? Of course, the kernel I have in use
now has long uptimes so it is sort of LTS for this rig anyway.
Do you REALLY want an LTS kernel? Sounds like you don't. You need to
update them just as much as any other kernel.
The point of an LTS kernel is it supposed to NOT receive feature
updates, just bug fixes. Given that Artificial Stupidity bots regularly
try to apply updates to stable kernels, is it worth restricting yourself
to old kernels? Especially when it's not unknown for a bot to try to backport a patch from kernel X+2, when it depends on a patch from X+1
that hasn't been backported, and anybody using that code finds their
"stable" kernel blowing up in their face.
The idea behind stable kernels is great. The implementation leaves a lot
to be desired and, as always, the reason is not enough manpower.
Cheers,
Wol
is wide ranging enough. </div><div><br></div><div>  I do agree that from what I know of Dale's usage he probably </div><div>doesn't NEED a long term support kernel, but he may be better </div><div>off with one.</div><div><br></div><div> If you are user of apps you pay for - in my case Mixbus - an paid</div><div>version of Ardour - and PixInsight then you are not going to get </div><div>much support if you're off in the weeds running Gentoo and/or</div><div>leading edge kernels.
On Sat, Nov 12, 2022 at 12:13 PM Wol <antlists@youngman.org.uk <mailto:antlists@youngman.org.uk>> wrote:
On 12/11/2022 18:22, Dale wrote:in use
Where does one go for a list of the LTS kernels? Since I reboot so rarely, what not use one of them?? Of course, the kernel I have
now has long uptimes so it is sort of LTS for this rig anyway.
Do you REALLY want an LTS kernel? Sounds like you don't. You need to
update them just as much as any other kernel.
The point of an LTS kernel is it supposed to NOT receive feature
updates, just bug fixes. Given that Artificial Stupidity bots regularly
try to apply updates to stable kernels, is it worth restricting yourself
 to old kernels? Especially when it's not unknown for a bot to try to backport a patch from kernel X+2, when it depends on a patch from X+1
that hasn't been backported, and anybody using that code finds their "stable" kernel blowing up in their face.
The idea behind stable kernels is great. The implementation leaves a lot
to be desired and, as always, the reason is not enough manpower.
Cheers,
Wol
Wol,
  While I don't completely disagree with your technical points I
really don't think your assessment of the purpose of a LTS kernel
is wide ranging enough.Â
  I do agree that from what I know of Dale's usage he probablyÂ
doesn't NEED a long term support kernel, but he may be betterÂ
off with one.
  If you are user of apps you pay for - in my case Mixbus - an paid version of Ardour - and PixInsight then you are not going to getÂ
much support if you're off in the weeds running Gentoo and/or
leading edge kernels. I run Kubuntu now, but not because I think
it's a better distro, but because I get support. Harrison does all
the dirty work on the audio stack and Pleiades Astro basically
says you're on your own running unless you are on just a couple of
distros. They were no help when I ran Gentoo. They are greatÂ
under Kubuntu.
  An additional point is that if Dale limits himself to an LTSÂ
kernel then he doesn't have to worry about changes to his
tool chain. I'm just waiting for the day that Rust becomes
a driving conversation point on this list. I don't think DaleÂ
wants or needs to be involved in that.
  Anyway, just my point of view.
Best wishes,
Mark
The idea behind stable kernels is great. The implementation leaves a lot
to be desired and, as always, the reason is not enough manpower.
Usually, I try to update about once a year. I don't change hardware
much.
On 12/11/2022 23:37, Dale wrote:
Usually, I try to update about once a year. I don't change hardware
much.
The main reason I suggested LTS is because that, *when* you decide to
do a @world update, you will get the latest LTS of the same main
version you're already using. For example you'll go from 5.15.20 to
5.15.78. And that means you won't have to bother with an array of
endless "make oldconfig" questions. There'll be like one or two at
most, which is trivial to deal with.
I've been using LTS kernels for years now, and I never looked back.
"make oldconfig" usually doesn't say anything, making it a
ridiculously fast and no-brainer update, and yet I get the latest
bugfixes and security fixes.
It just works :-)
Nikos Chantziaras wrote:
On 12/11/2022 23:37, Dale wrote:
Usually, I try to update about once a year. I don't change hardware
much.
The main reason I suggested LTS is because that, *when* you decide to
do a @world update, you will get the latest LTS of the same main
version you're already using. For example you'll go from 5.15.20 to 5.15.78. And that means you won't have to bother with an array of
endless "make oldconfig" questions. There'll be like one or two at
most, which is trivial to deal with.
I've been using LTS kernels for years now, and I never looked back.
"make oldconfig" usually doesn't say anything, making it a
ridiculously fast and no-brainer update, and yet I get the latest
bugfixes and security fixes.
It just works :-)
Thing is, I may go a year, sometimes more, without updating the kernel.
If I rebooted often, I could see using a LTS kernel. If a kernel can
run for months with no problems, it's stable enough for me. Plus my
hardware works.
I have even built a kernel but never actually booted it. By the time I
get around to rebooting, I've had to build another kernel. I generally always work from a known stable config tho. The only reason I wouldn't
is if I build a new system and have to start from scratch. I've also
had times when I had to update because my video drivers wouldn't build
with a older kernel version that I'm running. That doesn't happen to
often but I recall running into that at least once.
Either way, biggest question was if there was some known breakage
between my old version and a newer version. Maybe the one I tried just
had some weird problem that only affected me or I just missed something during the oldconfig. I wish I could recall the error. Who knows on
that.
Thanks.
Dale
:-) :-)
> > ridiculously fast and no-brainer update, and yet I get the latest<br>> > bugfixes and security fixes.<br>> ><br>> > It just works :-)<br>> ><br>> ><br>> ><br>><br>><br>> Thing is, I may go a year,sometimes more, without updating the kernel. <br>> If I rebooted often, I could see using a LTS kernel. If a kernel can<br>> run for months with no problems, it's stable enough for me. Plus my<br>> hardware works.<br>><br>> I have
<div>  While I completely understand your 'reboot once a year' POV, I think </div><div>you might *possibly* be missing the point Nikos and others are making.</div><div><br></div><div>  If you are on 5.14.XX you aren't currentlyusing a LTS kernel. The </div><div>LTS kernels would be the 5.10 and 5.15 series, according to <a href="http://kernel.org">kernel.org</a>.</div><div><br></div><div>  If you don't CARE what kernel you are running then why not build</div><div>5.15.
Thing is, I may go a year, sometimes more, without updating the kernel.
If I rebooted often, I could see using a LTS kernel. If a kernel can
run for months with no problems, it's stable enough for me. Plus my
hardware works.
I have even built a kernel but never actually booted it. By the time I
get around to rebooting, I've had to build another kernel. I generally always work from a known stable config tho. The only reason I wouldn't
is if I build a new system and have to start from scratch. I've also
had times when I had to update because my video drivers wouldn't build
with a older kernel version that I'm running. That doesn't happen to
often but I recall running into that at least once.
Either way, biggest question was if there was some known breakage
between my old version and a newer version. Maybe the one I tried just
had some weird problem that only affected me or I just missed something during the oldconfig. I wish I could recall the error. Who knows on
that.
Thanks.
Dale
:-) :-)
Shutting down your desktop applications and rebooting with a new kernel takes no longer than a couple of minutes. I mean even busy bank customer web portals have planned downtime.
On Monday, 14 November 2022 21:05:57 GMT Dale wrote:
Thing is, I may go a year, sometimes more, without updating the kernel.Keeping the same kernel running for long periods can leave you exposed to security vulnerabilities. Either stable or LTS kernels will be similarly exposed, if their latest backported versions are not booted with. I appreciate you're not running a public server so your profile is not as much at risk, but bad code in some application which hasn't been patched up could still leave you exposed.
If I rebooted often, I could see using a LTS kernel. If a kernel can
run for months with no problems, it's stable enough for me. Plus my
hardware works.
I have even built a kernel but never actually booted it. By the time IShutting down your desktop applications and rebooting with a new kernel takes no longer than a couple of minutes. I mean even busy bank customer web portals have planned downtime.
get around to rebooting, I've had to build another kernel. I generally
always work from a known stable config tho. The only reason I wouldn't
is if I build a new system and have to start from scratch. I've also
had times when I had to update because my video drivers wouldn't build
with a older kernel version that I'm running. That doesn't happen to
often but I recall running into that at least once.
Either way, biggest question was if there was some known breakageDid you diff your current good kernel .config and the new failed to boot kernel .config, to find out what options/modules have changed. Besides any booting errors, this could point you to something which was missed in the new kernel, or perhaps shouldn't have been configured. That's how I go about finding the cause of a non-booting kernel in the rare occasions I end up with a lemon.
between my old version and a newer version. Maybe the one I tried just
had some weird problem that only affected me or I just missed something
during the oldconfig. I wish I could recall the error. Who knows on
that.
Thanks.
Dale
:-) :-)
Shutting down your desktop applications and rebooting with a new
kernel takes no longer than a couple of minutes.
Howdy,
I been stuck on gentoo-sources 5.14.15 for a while. I tried upgrading
to I think 5.16 and then more recently 5.18. I upgraded like I always
do, copy .config over and run make oldconfig. Once I get everything in /boot, init thingy and all, I update grub. When I get around to
rebooting, the new kernels always fail part way through booting. I
can't recall the error since I last tried a newer kernel several months ago.Â
I'm about to try to jump to version 6.0.5 which is latest in the tree.Â
Is there some major change that causes copying .config file from 5.14 to
5.18 or higher to break? Do I need to configure a new kernel from
scratch in other words? While I try to answer each question the best I
can, either I'm breaking something or something else breaks preventing updating from older versions. I just don't know which it is. Me or it.Â
Thoughts?
Thanks.
Dale
:-)Â :-)Â
I'm back to my old kernel tho since my nvidia-drivers won't work with a kernel that high. I run into this on rare occasions.
On 2022-11-21, Dale <rdalek1967@gmail.com> wrote:
I did re-emerge the nvidia drivers for the old kernel. [...]
If I get bored, and it warms up a little, I may build a 5.19 kernel.
Thing is, by the time I get around to rebooting, nvidia may have updated and the new one I already got will work. :/
About 15 years ago, after a bad experience with ATI dropping Linux
driver support for a card that was only a year old (and no luck
getting the open source driver to work reliably),
I switched to NVidia
(mostly Qaudro cards -- fanless until that ceased to be an
option). They always worked great using the NVidia blob drivers, but
using NVidia drivers was a constant source of minor pain. Often kernel updates had to be postponed until NVidia driver support caught up, and
they too dropped support and forced me to replace a board that was
still working perfectly.
Eventually, I just gave up and started using built-in Intel
graphics. Life was much easier. A high-end gamer probably wouldn't be
happy, but my mid-range mainboard happily drove three decent-sized
displays (two DVI and one DP) at their native resolutions. I find the
same to be true on my newer AMD system with built-in Radeon Vega
graphics. It too "just works" with the in-kernel-tree support and
open-source Xorg drivers.
I did have to give up the option of having multiple X11 screens. The proprietary NVidia driver supported multiple screens, but the drivers
for built-in Intel and Radeon drivers don't seem to.
--
Grant
They always worked great using the NVidia blob drivers, but
using NVidia drivers was a constant source of minor pain. Often kernel updates had to be postponed until NVidia driver support caught up, and
they too dropped support and forced me to replace a board that was
still working perfectly.
On Monday, 21 November 2022 16:11:13 GMT Grant Edwards wrote:
I did have to give up the option of having multiple X11
screens. The proprietary NVidia driver supported multiple screens,
but the drivers for built-in Intel and Radeon drivers don't seem
to.
AMD APUs with embedded radeon graphics work fine here with two
monitors (DVI + HDMI ports).
I did re-emerge the nvidia drivers for the old kernel. [...]
If I get bored, and it warms up a little, I may build a 5.19 kernel.Â
Thing is, by the time I get around to rebooting, nvidia may have updated
and the new one I already got will work. :/
I don't personally remember NVidia ever dropping a card totally
but I did get confused for awhile when they started segmenting their
drivers by different families and it was up to me to figure out which
driver package handled my card.
On 2022-11-21, Michael <confabulate@kintzios.com> wrote:
On Monday, 21 November 2022 16:11:13 GMT Grant Edwards wrote:
I did have to give up the option of having multiple X11
screens. The proprietary NVidia driver supported multiple screens,
but the drivers for built-in Intel and Radeon drivers don't seem
to.
AMD APUs with embedded radeon graphics work fine here with two
monitors (DVI + HDMI ports).
Yes, multiple montors work fine with both Intel and Radeon embedded
graphics with Xorg drivers.
It's multiple X11 screens that isn't supported. An X11 screen is the
entity that's managed by single window manager and comprises what's
usually called "a desktop". A screen can include multiple monitors.
https://wiki.archlinux.org/title/multihead#Separate_screens
On Monday, 21 November 2022 16:50:14 GMT Grant Edwards wrote:
On 2022-11-21, Michael <confabulate@kintzios.com> wrote:
On Monday, 21 November 2022 16:11:13 GMT Grant Edwards wrote:
I did have to give up the option of having multiple X11
screens. The proprietary NVidia driver supported multiple screens,
but the drivers for built-in Intel and Radeon drivers don't seem
to.
AMD APUs with embedded radeon graphics work fine here with two
monitors (DVI + HDMI ports).
Yes, multiple montors work fine with both Intel and Radeon embedded
graphics with Xorg drivers.
It's multiple X11 screens that isn't supported. An X11 screen is the
entity that's managed by single window manager and comprises what's
usually called "a desktop". A screen can include multiple monitors.
https://wiki.archlinux.org/title/multihead#Separate_screens
You're right, I thought you meant two different monitors in Xinerama
style. I didn't know anyone who still uses separate displays
(screens) these days.
On 2022-11-21, Michael <confabulate@kintzios.com> wrote:
On Monday, 21 November 2022 16:50:14 GMT Grant Edwards wrote:
On 2022-11-21, Michael <confabulate@kintzios.com> wrote:
On Monday, 21 November 2022 16:11:13 GMT Grant Edwards wrote:
I did have to give up the option of having multiple X11
screens. The proprietary NVidia driver supported multiple screens,
but the drivers for built-in Intel and Radeon drivers don't seem
to.
AMD APUs with embedded radeon graphics work fine here with two
monitors (DVI + HDMI ports).
Yes, multiple montors work fine with both Intel and Radeon embedded
graphics with Xorg drivers.
It's multiple X11 screens that isn't supported. An X11 screen is the
entity that's managed by single window manager and comprises what's
usually called "a desktop". A screen can include multiple monitors.
https://wiki.archlinux.org/title/multihead#Separate_screens
You're right, I thought you meant two different monitors in Xinerama
style. I didn't know anyone who still uses separate displays
(screens) these days.
I found it very helpful when I dealing with interruptions (which is
about 50% of a typical day). I could flip one of the screens to a new
virtual desktop (while leaving my email and web browser as-is on the
other screen), deal with the interruption, then flip that screen back
to the desktop containing whatever I was origininally working on.
My office setup had three screens, each with four virtual desktops.
When using multiple screens, you develop the habit of using one screen
for common, always-on stuff (e.g. email, web browser) and the other
screen(s) for working on code (or whatever).
There are two main drawbacks to the multiple-screen setup:
* You can't drag a window from one screen to the other. With the
monitor sizes that are common now, that's not as big an annoyance
as it used to be.
* There are a few brain-dead (but vital) applications (e.g. Chrome)
that refuse to allow a user to run either multiple instances of the
application or allow windows on multiple screens (or X
servers). I'm a bit baffled by that restriction, but I'm sure it
allowed the developers to take some shortcut that saved 12 bytes of
data and 10 or 15 lines of code (out of many hundreds of megabytes
of occupied RAM and millions lines of code).
That said, you're right: using mulitple screens is no longer common.
It's not even supported by many desktops these days. I switched from
XFCE to openbox when XFCE dropped support for multiple screens.
--
Grant
On Monday, 21 November 2022 18:12:41 GMT Grant Edwards wrote:
You're right, I thought you meant two different monitors in Xinerama
style. I didn't know anyone who still uses separate displays
(screens) these days.
I found it very helpful when I dealing with interruptions (which is
about 50% of a typical day). I could flip one of the screens to a new
virtual desktop (while leaving my email and web browser as-is on the
other screen), deal with the interruption, then flip that screen back
to the desktop containing whatever I was origininally working on.
My office setup had three screens, each with four virtual desktops.
When using multiple screens, you develop the habit of using one screen
for common, always-on stuff (e.g. email, web browser) and the other
screen(s) for working on code (or whatever).
I found Enlightenment to be most versatile in this respect. Unlike
say Plasma, which has two monitors locked on the same virtual
desktop and when you switch to another virtual desktop *both*
monitors flip over,
in Enlightenment each monitor can switch to a different virtual
desktop independently. Like you, I keep always-on stuff on the left
monitor, while switching between different virtual desktops on the
right monitor.
There are two main drawbacks to the multiple-screen setup:
* You can't drag a window from one screen to the other. With the
monitor sizes that are common now, that's not as big an annoyance
as it used to be.
With Enlightenment you can move windows across monitors,
irrespective of the virtual desktop each monitor displays.
On 2022-11-21, Mark Knecht <markknecht@gmail.com> wrote:
I don't personally remember NVidia ever dropping a card totally
but I did get confused for awhile when they started segmenting their drivers by different families and it was up to me to figure out which driver package handled my card.
IIRC, towards the end, that card was still supported by the "legacy"
driver, but that required a kernel so old that other things I used
everyday wouldn't work.
<div><br></div><div>Thanks for the clarification.</div></div>
On Mon, Nov 21, 2022 at 1:10 AM Dale <rdalek1967@gmail.com> wrote:
I'm back to my old kernel tho since my nvidia-drivers won't work with aThey are only rare because you aren't updating regularly.
kernel that high. I run into this on rare occasions.
If you want to run external kernel modules like nvidia-drivers or zfs,
stick to a longterm kernel. The ABI changes all the time, and so
there will frequently be stable kernel version changes that break nvidia-drivers. Then there will be a lag before nvidia-drivers
supports the new stable kernel. In the meantime you can't run the
latest version, and that can mean security issues.
The longterm kernels rarely break nvidia-drivers and get all the
security and other fixes. They just don't get new features.
My office setup had three screens, each with four virtual desktops.
When using multiple screens, you develop the habit of using one screen
for common, always-on stuff (e.g. email, web browser) and the other
screen(s) for working on code (or whatever).
I found Enlightenment to be most versatile in this respect. Unlike
say Plasma, which has two monitors locked on the same virtual
desktop and when you switch to another virtual desktop *both*
monitors flip over,
That's how all of virtual-desktop window managers I've tried over the
decades work.
in Enlightenment each monitor can switch to a different virtual
desktop independently.
Separate displays is useful for multi-headed systems. I know a couple people who buy one, high-power desktop for the whole family and then attach multiple screens and input devices.more screens, but that's usually what you'd want). Attach the IO devices to the nested ones obviously.
If you want to do that, but your GPU can't handle multiple X displays, you can still set it up by using one master X server, and then running multiple, nested X servers, each given a specific region (which may or may not correspond precisely to one or
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 303 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 89:37:11 |
| Calls: | 6,812 |
| Calls today: | 4 |
| Files: | 12,328 |
| Messages: | 5,401,951 |