Honestly, this used to be the case, but the past couple of years Lenovo is going back to their old ways of sub-par upgradability, and sub-sub-par support across models for Linux. I believe the P-series is the current most compatible line.
You might want to consider getting a slightly older refurb you KNOW is very compatible versus a newer one, because it’s a crapshoot. Make sure to avoid any models with soldered memory (they specify on their site), and if you’re buying a modern AMD model, do some research and make sure they haven’t crippled any features in the BIOS.
If you’re not completely sold on Lenovo, look at getting a Framework laptop. It’s the most upgradable and repairable laptop of any kind out there.they also just started an outlet online store where they are selling last-gen models at deep discounts that you could upgrade to current Gen when the time comes.
Hey thanks, this outlet store thing may be just what I need! I wanted a framework but didn’t want to take out a second mortgage on my house! Lol that’s why I was considering Lenovo, black friday deals that I assume aren’t going to be on frameworks (but I’m still gonna check fri/mon) but are on the lenovos.
Correct. In the mission statement, Framework says they won’t be doing random sales, and prefer to keep prices consistent so customers know they are always getting the lowest price. I’m signed for an AMD 16", but those outlet prices are crazy good, so bought one of the 13" Intels as well to play with 😂
They may have been, things were far more trusting back then.
X servers, for example, would accept any connections. So we would often “export DISPLAY=friendscomputer:0.0” in the computer lab and then open windows of embarrassing content. Which at the time would likely be ASCII art…
One of my favourite wars was to open audio files on other people’s SPARCs, somebody had the loudest bag pipe music that usually ended things.
Access to the SPARCs was normally restricted to third year but if you knew the right person you could get an account created pretty easily. Had the fastest access to the internet at the time within the uni as well.
I used to work at a company that did distributed QA. Other people’s tests would run on your desktop. It worked surprisingly well. But occasionally a test of some audio resource would play on your speakers “The discrete cosine is a real, discrete version of the fast Fourier transform.”
I just tested it and unfortunately it did not fix the problem. Thing is, not Lutris nor Steam is picking up the gamepad. So I don’t see Steam eating the input, since it also doesn’t seem to recognize it.
Sorry, I misunderstood. What controller are you using? It seems odd that only jstest is detecting it. I initially needed to use an enviroment variable for my Steel series Stratus duo, but I think that was a layout issue.
I am really just using some very cheap off brand controller I found at some store. It does work on my RetroPie, but not my Debian pc. I have now switched over to my steam controller (since it works without any problems) and playing with it feels fine too.
So I guess I the problem has been solved for me, but the mystery of what causes this issue remains.
I’d suggest checking section 5.3 of the arch linux wiki gamepad page. Debian probably either has an older version of the related package or retroPie might have extra patches. Could not say what package for certain though. Arch Wiki Gamepad
What OP said. But here’s a more detailed answer courtesy of GPT-4:
Adding cat /dev/random > /dev/pty23 to your .profile would result in an interesting situation whenever you start a login shell.
Behavior of the Command: The command cat /dev/random continuously reads random data from the /dev/random device file, which generates an endless stream of random bytes. Redirecting this to /dev/pty23 means it attempts to write this data to the pseudo-terminal device /dev/pty23.
Impact on Shell Startup: When you add this to your .profile, every time you start a login shell (like when you open a new terminal session), it will execute this command. Since /dev/random produces an endless stream of data, the cat command will not terminate on its own. This means your shell will be stuck executing this command, and you won’t get a prompt to enter new commands.
Interactive Shell Issue: The shell remains technically interactive, but because the cat command doesn’t complete, you won’t get a chance to interact with it. The shell is effectively blocked by the cat command continuously running.
Potential Problems: There’s a possibility that /dev/pty23 might not exist on your system, or you might not have the permission to write to it. In such cases, the command would fail, but it would still block the shell if it doesn’t exit properly.
Fixing the Issue: To regain control of your shell, you might need to edit your .profile from a different context where it doesn’t get executed, like using a non-login shell or booting into a recovery mode.
In summary, it’s a kind of a “prank” command that can render your login shell unusable until you remove it from your .profile. It’s an example of how powerful shell startup scripts can be, and also a reminder to be cautious about what gets added to them!
It’s from the phrase “big wheel”, meaning a person with a lot of power/influence. Similar to “big cheese”… It would have been better to use “cheese” instead of “wheel” IMO.
Pretty sure it’s not. I saw something on this topic a few weeks ago but can’t quite remember. Iirc, it was a term in an early early OS, where a bit in memory was the privilege but and could be set or unset by turning a real wheel on the computer. This Stück with some people developing UNIX, so they called the wheel group wheel, but none of them are sure who came up with this.
Framework outlet is a great idea. I’ll add that I recently came across deals from Dell selling an XPS13 from 2020 for $449 and MSI selling an Intel powered laptop (no discrete GPU, almost office laptop) for $399. The older Thinkpads will be reliable though
Anyways, this probably depends on the application. You’d have to find out if there is a command line option in the application to start it minimised or in tray.
got a similar situation in MUDs, someone finds a way to frob everyone else up to wizard level and the whole round of the game just becomes a mess of shouts
Reminds me of the test server shenanigans I had at an old job versus a colleague. All in fun. Nothing in production.
One was the faux Bash shell that kind of worked OK until you pushed it or tried to do anything fancy. It was the default shell for the user called "root", but that wasn't the UID 0 user. It had been, but I renamed it. Then created a new "root" with a different UID. Of course, the faux shell would tell "root" that it was UID 0.
The other was the simple background loop that would detect any rival admin sessions and SIGHUP their shell process. First user on the box to run that pretty much had free reign, and everyone else was logged off instantly.
linux
Oldest
This magazine is from a federated server and may be incomplete. Browse more on the original instance.