What happened to real dual CPU’s?
They seem to have disappeared, at least in PC’s
1 Like
i still have two Sunblade dual Sparc systems - aint powered on either for 2+ years now - two physical uSparc RISC CPU with 16 GB RAM (actually one of them only has 8 GB)… I installed Solaris 10 on one of them and occasionally power it up… Setup ZFS boot mirror on one… Solaris 11 won’t run on this CPU though… I wasted several weeks (or months) trying to get POVRay ray tracer compiled on there - and - gave up.
I still have several motherboards with dual x86 (i386) CPU and one with dual 64 bit Opteron… At least two of them are pre-ATX (one supports dual Pentium MMX and the other one predates MMX). I have a dual CPU mobo with the old “Slot” series that Pentium II utilised (last use it had a pair of 466 mhz Celerons).
I’m guessing the power draw of physical SMP marked them uncompetitive with multiple core / threads on the same die (obvious).
When you can deploy 256 cores in a single blade with 24 or more “blades” in a chassis - physical SMP is probably only on massive enterprise “big blue” stuff like IBM AIX systems… But who knows - the way Broadcom have well and truly ENSHITTIFIED VMware - blade chassis hosting multiple VMware ESX hosts maybe a thing of the past.
I hope to see a lot of corporates shift to KVM or ProxMox…
2 Likes
The Vatican still uses VMWare, but they are not likely to be ahead of the trend
1 Like
strangely enough - earlier this year - I fell in love with a music album that scored #3 on a Vatican curated “best albums” list from the mid/late 2000’s…
It was David Crosby’s 1970 masterpiece “If I Could Only Remember My Name” (i.e. David Crosby of The Byrds and Crosby Stills Nash and Young) - which came out when I was 8 years old - and is now a mainstay on my playlist…
2 Likes
Seems I have to do this EVERY time there’s a new Ubuntu release - they remove, or move, some functionality…
Now - Ubuntu 24.10 on Latitude E7270 - goes into standby when I close the lid on the EFFing thing! WTF?
And the option to ignore that has been removed from Gnome Tweaks - WHY?
Some things suggest editing a file somewhere (can’t remember which) to disable monitoring the lid status - that didn’t work…
I DO NOT WANT my LINUX computers to SLEEP! Just sit idle 24x7 till I’m ready to use you again!
I want to do some ffmpeg tests to compare the 4 i7 cores (I think it’s actually 2 cores and 2 threads?) on the E7270 with Ubuntu 24.10 VS 4 Ryzen 5 cores (and 4 threads) running Pop!_OS 22.04… I’ve been using my desktop PC (Ryzen 7 and Pop!_OS) to ffmpeg convert files - and it makes the system unusable (I can do stuff - except listen to music or audio - when ffmpeg’s running - CPU sends a bunch of static onto the audio jack on the back of the mobo)…
I’d thought about using a Pi4 - but I don’t reckon that will cut the mustard…
Hmmm - I guess could I use ffmpeg on the 8 arm64 cores on either my my MacBooks… Why didn’t I think of that before???
I might actually re-format the Dell E7270 and put Ubuntu 24.04 on there… too many things borked in 24.10 (e.g. Sayonara looks like crap when using dark mode them - lack of Sayonara functionality is a show-stopper for me)…
1 Like
The file is logind.conf.
See reply #14 here
Try this
HandleLidSwitch=ignore
1 Like
Already mentioned - I tried one of the (main) suggestions - made no difference - when it still made no difference - I rebooted - still made no difference…
This is what I mean - every iteration of Ubuntu and/or Gnome - they change stuff…
Gnome Tweaks used to have a setting to you could toggle (that worked without rebooting) it’s gone and login.conf setting no longer works…
WHY CHANGE STUFF THAT WORKED BEFORE?
So frustrating… Never mind… it’s to be expected…
Just upgraded my personal MacBook Pro (M1) from 14.x to 15 “Sonoma” - and it broke nearly everything - like it didn’t even ask me if I wanted it to destroy my sudoers - no - it just wrote over it! Too much of shit like this happening these days…
I rrecently an some Red Hat “recommended” script / CLI snippet to make a system conform to the “Essential 8” . This was on a RHEL 9 system running in AWS EC2 - and - guess what? It overwrote the “nopasswd” setting in sudoers for “ec2-user” which is the only user you get by default when deploying Linux in EC2 - from “NOPASSWD” to having to use your password on EVERY sudo attempt - trouble is - if you’re not watching - you NEVER KNOW the password for “ec2-user” when you’re deploying from an AMZN AMI RHEL image into EC2… Lucky I caught this beforehand - and had changed, and “known” the ec2-user password… I’d have been well and truly F–KED if I hadn’t done this… and I wasn’t really ready for it - it was fortuitous I’d actually set a password on that user account! FFS!
1 Like
Stuff like this - from the main “mainstream” distro - is why Linux desktop will never be a main player…
I love Linux - and prefer the Ubuntu derived variants (Ubuntu itself, or the likes of Pop!_OS) - or just (mostly) plain debian on ARM (i.e. Raspbian)…
But why break something that worked before?
2 Likes
Well, it is not really satisfactory.
Sometimes there are good reasons for change, but this sounds like aimless fiddling.
I wonder is the quality of staff at Ubuntu declining?
It sheets home to the people behind the release.
Conway’s law
“Any piece of software reflects the organizational structure that produced it.
(Interesting example of how this can cause problems: NASA’s Mars Climate Orbiter crashed because one development team used English units while the other used metric units to control the thrusters.)~”
1 Like
Had to confine my searching by date - because I was coming up with invalid advice from 10+ years ago - way way deprecated…
Installed and use dconf-editor - navigated to :
/org/gnome/settings-daemon/plugins/power/lid-close-battery-action
And set value to “Nothing” - which did nothing (other than suspend the device!)
then tried “Blank” - which also suspended the device!
THAT’S NOT WHAT I WANT!!!
Had pending updates anyway - so rebooted…
IT’S STILL NOT working - i.e. close lid and it goes into suspend - and - forces me to re-type my login / password! WTF?
I have Ubuntu set to autologin on boot up - this doesn’t bother me - 'cause I have LUKS on my root disk - and a I have a reasonably complex password to unlock encryption - and if I ever go anywhere with the laptop powered on - I’ll manually lock my system!
Pezzo di merda!
I discovered that something had overwritten my changes to /etc/systemd/logind.conf…
So I edited it again - and have :
HandleLidSwitch=blank
HandleLidSwitchExternalPower=blank
HandleLidSwitchDocked=ignore
Closed lid on AC power - and sure enough - it went into suspend (I can easily tell 'cause I lose my SSH remote session to it).
Rebooted - unlocked my LUKS root partition…
Closed lid on AC power - and sure enough - it again went into suspend…
Sheezuz this is frustrating!
Defo time to wipe this piece crap and install Ubuntu 24.04 on it… Hmm - even 24.04 gnome tweaks doesn’t have the “ignore lid close” toggle! Just looked at 24.04 running on my Pi5…
Maybe I’ll revert back to Pop!_OS… it’s not as “pretty” on Gnome 42 as Ubuntu is on Gnome 46 (Ubuntu 24.04) or 47 (Ubuntu 24.10 - but Sayonara music player looks VERY ugly on 24.10!)… But at least I can reliably rely on closing the lid (even when on AC power) not suspending… I use ALL my Linux (and MacOS) devices as Linux/UNIX servers over SSH and don’t want ANY of them going into suspend! I’m pretty sure MacOS - even when in “low power mode” (seemingly suspended) will wake up on receiving an SSH connection…
1 Like
I thought there was something about heat problems if you close the lid of a laptop while it is running ?
Autologin works on boot, but not on suspend?
1 Like
Solved that by disabling “Lock Screen on Suspend” setting under Privacy and Security… So now when I wake it up - I don’t have to login…
But haven’t solved why it suspends when I close the lid whether on battery or AC power… Nothing I’ve tried fixes that…
I want to close the lid - but still be able to SSH to it if I need to…
e.g. one of my favourite CLI utils (Python) “bandcamp-downloader” is broken on my main Pop!_OS desktop system - so I ssh somewhere else to run it… At the moment I’m SSH’ing to my Pi4 system running Debian 12…
1 Like
Have you looked at the stuff in login.conf?
1 Like
Yes (I did already - several times):
Such a PITA - as I have to reboot (or logout)…
Trying :
LidSwitchIgnoreInhibited=no
(default is “yes”)
And that seemed to do it… Rebooted - unlocked my LUKS - let it autologin…
SSH’d to it - ran btop…
Closed lid - btop display over SSH connection still showing…
SSH to it again - can login over SSH while lid’s closed…
That “LidSwitchIgnoreInhibited” is very confusing… But I guess it overrides ANY other “thing” you’ve tried…
SOLVED!
Note : I also tried this (changed “blank” to “ignore”) :
HandleLidSwitch=ignore
HandleLidSwitchExternalPower=ignore
HandleLidSwitchDocked=ignore
So I cannot be 100% sure which change fixed it… I’d rather have it blank the screen when I shut the lid - but does the hardware turn off the display on lid close? Is it like the refrigerator light (which makes me think of Alice Cooper’s “Cold Ethyl” 
)…
BTW - still haven’t solved why Sayonara looks so ugly (on Ubuntu 24.10) and ignores my theme tweaking (it makes the titlebar white in dark mode, and puts the widgets on the right - everything else has the Window Control widgets on the left).
Gnome Tweaks on Ubuntu 24.10 :
Sayonara 1.10.0-stable-1 on Ubuntu 24.10 on Dell Latitude 7270 :
(looks the same whether running as a snap, or installed via apt install)
Sayonara 1.8.0-beta1 on Ubuntu 24.04 on RPi5 :
Sayonara 1.7.0-stable3 on Pop!_OS 22.04 on Ryzen 7 desktop :
I suspect its maybe some GDK or QT library rendering that application title-bar (white on Ubu 24.10) - some other apps completely ignore what you’ve tweaked in gnome too - like Steam, and Microsoft Teams (both of which are effectively just web browsers).
I guess maybe one solution would be to revert to an older version - tried removing the DEB install and use a snap instead - the snap version of Sayonara on Ubu 24.10 is the same as that from the repo…
Interestingly the screenshots of the app (https://sayonara-player.com/) - in “dark mode” have a white / gray window title bar - so it looks like the app is drawing its own titlebar? Or is this a Wayland thing? Further testing required…
I have occasionally seen the developer pop their head in here from time to time… and it’s probably about time I patreon’d him again… which reminds me I should really subscribe $$$ to this forum…
1 Like
Update : solved Sayonara display issue on 24.10 by running the appimage of 1.8.0-beta1
SOLVED 24.10 issues :
- suspend on close lid
- sayonara window titlebar white on dark mode
So I guess I’ll keep running 24.10 on this Latitude E7270…
Also - the display stays on with the lid closed - so I might try it with “blank” again (which means reboot / logout) from :
HandleLidSwitch=ignore
HandleLidSwitchExternalPower=ignore
to :
HandleLidSwitch=blank
HandleLidSwitchExternalPower=blank
And 'cause I’m lazy (as root via “sudo -i”) :
root@mimas:/etc/systemd# sed -i 's/HandleLidSwitch\=ignore/HandleLidSwitch\=blank/' logind.conf
root@mimas:/etc/systemd# sed -i 's/HandleLidSwitchExternalPower\=ignore/HandleLidSwitchExternalPower\=blank/' logind.conf
root@mimas:/etc/systemd# grep blank logind.conf
HandleLidSwitch=blank
HandleLidSwitchExternalPower=blank
root@mimas:/etc/systemd# sync && shutdown -r now
all of the above are good and valid reason why Linux Desktop isn’t as popular as it could potentially be - “just sayin’” - I don’t have an answer - and really I don’t particularly care - I’m no evangelist - if you’re happier on Windows or MacOS - by all means - keep using them
1 Like
Another double negative… I hate them.
I dont think you want the screen on when lid is closed… thats a lot of power and heat.
At least you go there.
2 Likes
Not quite there yet… I spoke / wrote too soon…
Turns out “ignore” doesn’t work - it still goes into standby when on AC power when lid closes - maybe takes just a tad longer…
There’s probably some new fangled systemd thing I need to stop or disable or whatevs…
I DO want the screen to blank when I close the lid, I DON’T want the machine to susped and go offline (and stop listening to incoming, or extant, remote SSH clients) when I close the lid… This is something so basic - I can’t believe how convoluted and messy it is!
╭─x@mimas ~
╰─➤ grep -v \# /etc/systemd/logind.conf
[Login]
HandleLidSwitch=blank
HandleLidSwitchExternalPower=blank
HandleLidSwitchDocked=ignore
LidSwitchIgnoreInhibited=no
Yeah - there’s
suspend.target
and
systemd-suspend.service
But neither show as running. I set both to disabled but I see this :
╭─x@mimas ~
╰─➤ sudo systemctl disable systemd-suspend.service
The unit files have no installation config (WantedBy=, RequiredBy=, UpheldBy=,
Also=, or Alias= settings in the [Install] section, and DefaultInstance= for
template units). This means they are not meant to be enabled or disabled using systemctl.
Possible reasons for having these kinds of units are:
• A unit may be statically enabled by being symlinked from another unit's
.wants/, .requires/, or .upholds/ directory.
• A unit's purpose may be to act as a helper for some other unit which has
a requirement dependency on it.
• A unit may be started when needed via activation (socket, path, timer,
D-Bus, udev, scripted systemctl call, ...).
• In case of template units, the unit is meant to be enabled with some
instance name specified.
Yeah - I know - some of you hate systemd - but I have to use it in my job all the time - it’s ubiquitous. I’m not about to start distro hopping or various niche alternate init systems.
Just found another cunning bastard : /etc/systemd/sleep.conf… WTF?
Anyway - I uncommented and changed the values :
AllowSuspend=no
AllowHybridSleep=no
(default is commented out and “yes”)
That seems to have done the trick - without even having to logout or reboot…
Laptop’s on AC power - lid is closed - 15 minutes after closing lid I can still ssh to it…
1 Like
Fair enough. You have to work with what is there. I dont hate it, just have a feeling it could be done better.
Anyway, you did succeed eventually. I would never have thought closing the lid would interact with the init system.
login.conf is a confusing mess.
1 Like
It sure is…
And - I noticed - it’s not suspending - but it is timing out my remote SSH session…
So I’ve had to update /etc/ssh/sshd_config and set :
TCPKeepAlive no
ClientAliveInterval 30
ClientAliveCountMax 240
and annoyingly the ssh daemon seems to get various names and they seem to change it every few iterations…
e.g.
sudo systemctl restart sshd doesn’t work
sudo systemctl restart openssh-server doesn’t work either…
Annoyingly - the systemd “service” to run sshd is now called just “ssh” - WTF? When did that change?
Anyway :
sudo systemctl restart ssh
I hate that - the daemon should be SSHD - “ssh” is the client!
Boy some of those hideous security scripts / profiles do some horrible stuff to sshd_config… e.g. installing RHEL with a CIS1 or a CIS2 profile has hideous inactivity time-outs… a real PITA… And so does running Red Hat’s “Essential 8” script…
1 Like
There are 3 things
Package name: openssh-server, openssh-client
Service Name: ssh
Daemon name: sshd
(That is as in my Devuan)
and it is not just ssh … the names differ for every app, and they are not the same in different distros, and they are not the same in different init systems.
In sysVinit you can get list of service names from /etc/init.d. I dont know where you look in systemd.
In Antix and MX there is a GUI service manager, and it lists them.
In Void/runit the service names are in /etc/runit/runsvdir/current… and Yes, Void/runit calls the service sshd not ssh. One up for Void here!
I have more trouble with package names than anything else.
1 Like