I hate linux for this. How the hell a modern OS can be frozen completely shut by some runaway python script running in a VS code debugger, to a point that you have to kill your PC with a button. And then non-obvious issues that just "appear" out of nowhere and steal your perfectly fine evening where you have planned to work on your favorite side project.
It’s a reappearing issue with Linux that you run into problems other operating systems don’t have to this degree. Which is sad, because seeing the direction Windows 11 is heading towards, I’d like for Linux to achieve widespread adoption.
If you want that, then use it and contribute. That's the only way widespread adoption will happen.
Contribution does not necessarily mean code. It can be documentation, design, UX, sharing information, or just working getting people familiar with Linux.
My story, I bought a new widget, a gaming wheel a few years back, and it did not work on my Windows machine, I even reinstalled Windows, installed the drivers from disk it did not work. I send the thing back and report it broken and the guys call me to report that works perfectly. In the end I bought a different model that worked both on Windows and Linux.
So a gadget with official Windows support did not work on my machine, even after I wasted my time reinstalling Windows just in case but worked fine for some support people.
I had a diffrent experience with a USB WifFi antenna , it come with a mini CD with drivers but my PC had no CD Drive, there was no online source for that no name brnd.
I plugged it on a Linux machine and it worked, then I done a lsusb and found the real chip powering the device, then Googled for that I found a compatible Windows driver on a drivers website and I fixed it for Windows machine.
Linux has problems, but install a LTS distro on compatible hardware and you should not have issues for a few years.
To balance things, my latest bad experience in KDE was when Kwin crashed and refused to enable compositing again printing a vague reason in the logs, I found using Google that KWin put an isOPenGLSafe=false in soem log file and refused to start compositing but for some reason (maybe is a valid one) was incapable to print also that "I refuse to start compositing because of this setting - lesson for us devs, when we put stuff in log messages, put as much info as possible
Oh don’t worry as a daily user of windows 11 I can assure you that Microsoft is doubling down on random mystifying problems, paired with no useful forum for users to collectively figure things out.
> It’s a reappearing issue with Linux that you run into problems other operating systems don’t have to this degree.
I've supported both professionally, and no, you don't. I blame the claim on a lot of people using commercial operating systems feeling a bit guilty, like they're supposed to be on Linux to be a real developer. They respond by criticizing an OS that they don't really use for the problems that they imagine happen all the time. Instead, what's happening is that they, personally, always run into problems trying to figure out why something won't work in prod, or trying to get their VMs to work like the tutorial, and they assume that people who use Linux as a daily driver run into problems at that rate. They never pay attention to Linux unless something critical has already broken.
Also, whenever they decide that they're going to try Linux again to see if it's ready for them yet, they always choose Arch (it used to be Gentoo) or the latest trendy distro that has a MacOS aping desktop. Just install Debian, it's easy.
Thunderbolt isn't that well supported, and they decided to specifically not use USB3 which is well supported for bogus reasons. #1 rule with Linux is pick well supported hardware.
> How the hell a modern OS can be frozen completely shut by some runaway python script running in a VS code
That isn't a just Linux thing. You can easily fork-bomb (or equivalent) Windows/iOS/other and so forth, especially (though not only) if running as a privileged user.
> And then non-obvious issues that just "appear" out of nowhere
That is definitely not something that I've never seen when using Windows! Where it has happened to me under Linux it has been eventually traced to a hardware issue or a bad update (the latter I've experienced on both those OSs over the years and the former will affect everything).
> That isn't a just Linux thing. You can easily fork-bomb (or equivalent) Windows/iOS/other and so forth, especially (though not only) if running as a privileged user.
I've crashed DWM with WSL before, by doing something completely unrelated to Windows.
What happens is you start getting the solitaire effect because suddenly no windows have graphics buffers anymore
> > And then non-obvious issues that just "appear" out of nowhere
>That is definitely not something that I've never seen when using Windows!
Case in point: my laptop (running the Windows 10 it came with) recently stopped hibernating properly, well it hibernates OK but half the time when it wakes up the screen does not turn on, and this evening it has decided that it doesn't want to be asleep while plugged in. If I tell it to sleep (through power key or start menu) while plugged in it does very temporarily and then returns to the login screen. If I tell it to sleep when running on battery it does but immediately wakes up once power is connected.
While Linux distros are far from free from random problems at times, in my experience Windows exhibits them more and tends to be harder to diagnose because more is hidden.
Linux will free memory that's backed by files, and load it again when it's needed. Under heavy memory pressure this has the same effect as swap thrashing, even if you have swap disabled. The kernel's out-of-memory killer does not help, because it's designed to work only as a last resort, and the system is still technically making progress despite being unusable in practice. AFAIK no other mainstream OS has this problem.
The solution is running a userspace out-of-memory killer, e.g. earlyoom.
Yes, sometimes you land in these situations in Linux, but many times are self inflicted by unnecesary tinkering.
I cannot see why dealing with all the … unwanted things from windows can ever be better. With mac if it is too new it will not be supported and after a few years you need to upgrade your hardware or are left to die. Apart from being an exclusive system for the rich.
This is why I run Fedora Silverblue. My Linux is now an appliance that upgrades atomically. If something breaks, I rollback. Once in a while, I pin a version that is known to work so it never gets garbage collected.
The other day I changed /etc/ld.so.conf and the system would not boot—my fault. I choose the previous deployment in GRUB and I had a working system back.
MX here. Rock stable for my purposes. I have one Windows system for some proprietary stuff I need. Other than that it's been Linux for about 10 years now.
A lot of my problems are from tinkering as well but that's why I am using linux, to control it better and tinker with it. Why won't I just use macos if I wanted something I can't tinker with? I think people lose sight if why Linux even exists to begin with, it is all about user control and ability to tinker/hack it.
I think better UX and more configurability would solve this stuff (from a friendly interface). The reason desktop/distro people won't do that is because it is considered bad UX practice to have too many decisions for the user. But imo, a Linux user would be an exception. In an ideal world, whoever decided to disable the boot flag in this case should have provided an easy to access distro/de setting to flip it back on.
Yes, a lot of times when i have «Linux problems» is because i am installing it in hardware that was not made for it. For example, old Macs, but usually after an evening i get decent results. Have few old macs with Lunux that work nicely. :)
Nail in the coffin for me yesterday when I restarted my computer to boot into windows and it had a splash screen begging me to "upgrade" to windows 11. I click no, another splash screen begging me in other terms. I click "no" (actually, no, it was probably more like "some other time" or "remind me again in the future"), ANOTHER SPLASH SCREEN.
Mind you I have my grub set to boot into windows by default so that if there's a power outage, my game streaming and backup setup, which is on my windows partition for now, will relaunch if I'm traveling or something. Yet if it had booted into that stupid splash screen, Steam and etc won't have been able to launch, and I'd have been SOL!
I hate windows!!!!! I can't wait to get EVERYTHING onto linux. I have a todo to see about using proton compatibility for desktop gaming, it works great on steam deck. After that the only remaining thing is ableton, and I'll have been completely freed from windows forever!
> I cannot see why dealing with all the … unwanted things from windows can ever be better.
Because the amount of time spent on unwanted Windows things is radically less than the amount of time spent on Linux evenings.
Windows does by and large just work. Every OS has warts and bugs. I want to spend the absolute minimum time on them.
Linux is getting better and may not require too many Linux evenings these days. But that’s really only true if you’ve burned hundreds of hours dealing with increasingly obscure Linux errors.
It’s not too hard to understand why different people prefer Linux, Mac, or even Windows. They all have pros and cons.
Couldn't agree more with the takeaways. Especially #3 - and it is exacerbated if you are a finicky person who wants everything exactly the way you want it + loves to customize and tinker. Linux basically keeps me hooked by virtue of catering to those needs even though I have to deal with these Linux evenings (which are thankfully getting rarer over time). In time too because my tolerance is depleting as I age and have decreasing bandwidth to deal with all that. Also the reason I always dual boot with Windows.
I also have a somewhat interesting usecase that doesn't let me switch to Mac (not that I am keen to). If I buy a Mac, I will have to switch my phone to iPhone too because integration with Android isn't nearly as good. However I _must_ have a dual sim phone (which is fairly easy with Android) and there aren't any dual sim models of iPhone.
I used to have a dual physical SIM iPhone X from China! However, when I sent it in to get (warranty) a local Apple repair shop screwed up and replaced it with a North American model. After much gnashing of teeth with Apple Support, I wound up with a new iPhone 12…but no dual physical SIM.
Now my phone is still confused after restoring from backup and cannot see the eSIM. I’ve been filing feedbacks and radars to no avail. If I was on Android I’d have just rooted it and deleted the offending (mis)configuration file already!
Not sure if this would help, but I recently learned about a product called iMazing[1] that lets you browse and edit iTunes backups.
You can't access the whole filesystem of a running iDevice with it, but you can access the whole filesystem of the backup. So I suspect it might be possible for you to clean-up the backup offline & then restore it. (At a minimum it should enable you to extract the valuable contents out of the backup and manually restore it on top of a clean iOS install.)
I've used it with some success to extract info from the photos database. I just wish they had a consumer-facing (read: more affordable/perpetually licensed) version of their CLI tool.
I cannot recall the specifics but I remember that there were some issues with eSIMs for certain use cases (possible that those were teething troubles that have been resolved).
Also, I like the flexibility of using the physical SIM because I can easily use them with both smart and feature phones without issues.
What kind of android integration do you require, out of curiosity?
I use iPhone + Mac, but I don’t remember any hiccups when it was android + Mac. Most of my interaction between the devices is pretty indirect anyway (photos are shared through google cloud, etc).
The main one I have is Syncthing[0]. I have a fairly involved file sync setup across several Android and Linux devices and it works beautifully; I like that I can use the space available on my devices instead of having to depend on/pay money for cloud (I know that it is not much for most of us). However, to best of my knowledge, Syncthing doesn't run on iPhone (it is possible that jailbreaking etc can make that work but that is a whole different area).
Side note: I've been working on creating a new blog now that I've completed my name change (and whatever other aspects of my transition affect my public persona). This blog's minimalism is still distinctively styled and I'd like to do something visually similar. The choice to make it black-on-light-gray is somewhat pleasing. Has a consensus been reached on dark styling affecting readability?
Some like it, some overdo it. Apparently many live in darkened caves and use dark mode all day. And for me too much contrast in dark mode means harder to read because the white bleeds into the background. YMMV.
I mean it's obviously a kernel bug.
Now I wonder if it's nice to have a way to work around them, or if these work arounds are detrimental to them ever getting fixed properly.
Thunderbolt devices appear in the OS as a PCIe switch, so you need two additional bus numbers (one for the Switch Upstream Port and one for the Switch Downstream Port). If the device is hotplugged to a port which has run out of bus numbers, you'll get this error message.
Mika Westerberg is constantly fine-tuning the allocation of PCI resources in the Linux kernel to avoid such scenarios. Some recent patches:
We don't have that on Linux unfortunately, so we depend on getting the initial resource allocation right.
Sergei Miroshnichenko has worked on such a reallocation feature for Linux but it hasn't been accepted into mainline yet and he hasn't posted a new version of his patches for almost two years, so the effort seems stalled:
It sounds like the pause/unpause might be the way to fix this properly, since trying to be heuristically smarter sounds like a recipe for never-ending corner case bugs like the OP’s issue.
The patch for pausing and unpausing seems quite reasonable, except that it does require driver support (unsurprising - you’re literally reallocating the resources used by the driver!). I suppose if you had at least a few movable devices then you should be ok in the event of a hotplug event, so you’d have to hope that enough drivers bother to support the feature.
I wonder what is necessary to get people to care about the patch enough to fix it up and mainline it? I suppose the problem it fixes is still niche enough that not so many people are clamoring for the fix.
While tongue in cheek, the answer is accurate: open source does not mean "free service contract", it means that you can take the code and modify yourself (and preferably upstream the fix).
Patches come both from vendors and users experiencing an issue. Vendors take care of most things, but for esoteric problems you might only have a handful of people experiencing it. The vendor is unlikely to care, so if you do not write the patch or pay someone to do it, who will?
Still better than the competition, where such problems will never be fixed unless it generates sufficient bad PR...
You're doing the same thing, dragging the original conversation off into berating the commentor for not fixing it themselves because you owe them nothing and they shouldn't be so entitled.
> "Still better than the competition, where such problems will never be fixed unless it generates sufficient bad PR..."
The competition comes under "pay someone else to do it".
What OS are you using where you can get the vendor to implement kernel features to fix obscure driver issues?
I'm sure there's an amount of money you can throw at Microsoft to get something done. I don't know how much it is, but I'm guessing it's more than it would cost to find a vendor to do it for Linux.
The serious answer to " What is the point in having all of the drivers be open sourced and mainlined if we're not willing to fix them to support this?" is "There are many points to this, but one of them is that it's possible to fix them to support it, if someone wants to put in the effort. It's worth something that it's theoretically possible if you really need it, even if no one else has done it yet.".
The answer "You can do it yourself" is meant to help them understand "Anyone can do it, someone needs to step up to the plate. But it's also true that it costs resources. If you're wondering why no one else has done it yet, it's the same reason you haven't done it yet".
> You're doing the same thing, dragging the original conversation off into berating the commentor for not fixing it themselves because you owe them nothing and they shouldn't be so entitled.
Ah, this argument again. Yeah, the maintainers owe you nothing, as they have already worked their asses off to give you something for free. You have the right to make polite bug reports and discuss fixes, but no one is entitled to force volunteers to do work.
But, that is not the same thing as everyone having to fix their own shit. 100 million users does not need 100 million developers.
What matters is that the users that have issues can fix issues, and if the issue affects enough people, it will eventually affect someone able and willing to fix it. That is why open source works, but it requires that some people put in the effort, and many learn to do it exactly when they get annoyed by a bug.
So yeah, if you are not willing to wait for someone else to come around and volunteer to fix it, patch it yourself or pay someone else to do it. That's how the system works, regardless of how demeaning you feel this is to non-developers or developers that feel that their time is more valuable than that of others.
> The competition comes under "pay someone else to do it".
Sure, if you have enough money to convince Apple or Microsoft specifically to prioritize fixing your issue (which may be in an unsupported or deprecated configuration) above what else they were doing, which would cost a whole lot more than just engineer and manager time. You have no alternative, as only your specific vendor can make the fix. Realistically speaking, if you had that kind of money you probably already have employed engineers that you could get to fix your open source issues for you and would not be arguing on hacker news about the need to write patches.
For open source, you don't have to convince anyone in particular. Can't convince the first person you try with money? Just ask the next person, anyone can submit the patch.
I think you are mixing two arguments. One is a good, valid, argument which is about how volunteer maintainers don't owe anyone anything, and absolutely don't deserve to be harassed, insulted, coerced, guilt tripped, etc. And the other is is about internet Linux commenters (away from bug trackers and issue lists) replying in ways that close down and end conversation of anything which isn't toeing the 'party line' of how great Linux/FOSS/libre/gratis software/etc. is.
The parent comment by AnIdiotOnTheNet was not in the context of bug reports filed to maintainers, or insulting anyone, or demanding anything specific. The parent of that said that the patch looked good "but" would need driver support, perhaps suggesting that's a showstopper. AnIdiotOnTheNet asked what the point of having open source drivers is if they can't be fixed, or charitably steelmanned read as "the drivers are open so they can be fixed to work with the patch". Blueflow's reply "you are free to submit a patch" is technically correct, but low value - few people on HN aren't aware of that. The following "or request a refund" is conversation ending, "fix it or shut up, stop talking about it".
It's a common reply format on internet Linux discussions which is closer to 'silence wrongthink' or 'cancel culture' than tech discussion.
> "So yeah, if you are not willing to wait for someone else to come around and volunteer to fix it, patch it yourself or pay someone else to do it."
Or ... talk about it, rant about it, 'raise awareness', exercise freedom of speech. "Patch it or shut up" aren't the only options. And look, dkozel replied with a long and technically detailed comment[1] and didn't need anyone jumping in to silence unapproved questions.
Your ideas and intentions might be good and noble, but in the end of the day its the contributors and maintainers who burn out. And from my impression, most people in OSS are already fed up with supporting users. And I'm too. Telling users off like "fix it or shut up, stop talking about it" is the necessary step to protect yourself.
What it sounds like you’re saying is “If you don’t know how to code, GTFO” because in all likelihood the parent made this comment because they’re not capable.
Not quite. If you are a non-developer not patient enough to wait for others to volunteer, or are a developer thinking that your time is somehow more valuable than those of the maintainers, then GTFO. :)
Waiting patiently and politely reporting bugs is a fine strategy: If a problem affects enough people, it will eventually affect a developer capable and willing to fix it. If you want it go faster, you will have to get your hands dirty - many contributors acquired the skills exactly because they were annoyed by an issue and decided to fix it.
Where did AnIdiotOnTheNet's comment include not being a developer, not being patient, or thinking their time is more valuable than others?
Why is it so much more important to put someone in their place and win internet points with ad-homs in the "community" which supposedly values freedom?
"Whats the point in ${enormous amount of work others did for me for free} ..." is never a polite move. Neither is your second sentence.
You two are just rude. No amount of freedom forces other people to bear with that. And if you think its not rude, still, the world is large enough to avoid each other.
> ""Whats the point in ${enormous amount of work others did for me for free} ...""
That is the least charitable interpretation of it, and I think not at all what it actually says.A much better reading of it is, paraphrased:
"The PCI-e patch is nice, but it would be a dealbreaker waiting on driver support."
"The drivers are open source and checked into the same tree, so there's no dealbreaker there in waiting for vendors or coordinating with third party organisations and their release schedules {and that's the point of desiring open source drivers, so the system isn't hobbled by binary blob drivers and vendor release schedules}".
Very poor choice of words. If the deal is bad, request a refund!
I understand what you are trying to say, but i think that's just entitlement.
Just accept that, as a non-contributing OSS user, you have zero leverage over which features other people pour their energy into. If you do, that's a charitable exception and happens at the generosity of the one doing the work for you.
Edit: Let me quote the licensing terms that you agreed to and gave you permission to use the linux kernel at all:
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
Can you get off your high horse about finding someone to punish for some imaginary sin which hasn't even been committed in this thread, and respond to some of the things I said and the points I made?
The "deal" in question was imaginary person A offering patches to the kernel to fix the articles's PCIe allocation, and the Kernel maintainers hypothetically refusing the patches on the grounds that it would break compatibility with drivers and so it cannot happen. Then the comment that the drivers could be updated to match, so the patch could hypothetically happen. There is NO entitlement anywhere in this imaginary scenario, there is no demand for anyone to write such patch, no expectation that someone get right on updating the drivers, no insinuation that someone owes a review of such a patch, nothing that you are so het up about has happened or been implied to happen, been demanded, expected, requested, suggested or implied.
> "Just accept that, as a non-contributing OSS user, you have zero leverage over which features other people pour their energy into."
Where did you come up with the idea that I am a non-contributing OSS user? Because it drives your superiority fantasy, I suspect, where "putdowns of the inferior" are the order of the day.
Why not? You don’t think it changes the topic from being about the content of the comment (open source drivers) to being about the person who wrote the comment (what they should and shouldn’t be permitted to say based on how much they paid or didn’t pay)?
You have not shown any signs of this spectre of entitlement haunting your every comment. If you had, an appropriate response would be educational, helpful, or perhaps a link to Rich Hickey's Gist[1].
By your comments, it would be appropriate to ad-hom you now for your apparent entitlement to controling other people's speech about OSS, right?
Its simpler: your attitude is bad, i told you off, you have no intentions to change your attitude, neither do i.
And if thats "controling other people's speech" to you, then yes, your attitude is the problem. Realistically, i'm just some random dude on this forum, telling you off is the worst thing i can do to you.
> "you have no intentions to change your attitude, neither do i."
Multiple times now I have pointed out that I have not shown the behaviours you are accusing me of. The difference of who has intentions to change is that you are wrong.
> “i'm just some random dude on this forum, telling you of”
You are doing so like a teacher with the wrong understanding, and despite being corrected you are intent on making sure someone gets told off whether it’s appropriate or not.
> Enjoy your refund.
You are free to link to the place in this thread where I personally said I was unsatisfied with some piece of software, or unsatisfied with the work someone was doing on it, or in any way mentioned desiring a refund or expecting more work? I think you won't be able to find such a place, so your 'clever comment' falls flat.
Possibly it is hard, tedious, or the people able to fix it don’t think it is worth the effort.
Open source projects rely on volunteers mostly so it isn’t like there’s some outside force to appeal to. If nobody volunteers a solution, then it isn’t important enough to solve. The point is that, if it were important enough to fix, anybody with the requisite skills could do so.
Maybe it can be introduced gradually, making the reallocation an optional feature that a driver might support. Then drivers can independently implement the resource reallocation feature.
Mainline drivers can move gradually. If they want to be nice for out-of-tree drivers then they can describe a timeline for deprecating and removing the support for non-reallocating drivers.
Would a workaround be that whenever the kernel detects this happening (and it did, it dmesg printed it) that it somehow increases an internal counter so on next reboot there will be more resources?
This would require the kernel being able to either update its own command line somehow, or having some permanent storage somewhere it could store it.
Or this could all be done by systemd - detect that message, increase the resource, next reboot will fix it.
The PCI resource allocation code is fairly intricate and everyone is scared that changing it may cause regressions. Sergei's patch set is quite intrusive and it would be necessary to somehow break it up into smaller pieces that are slowly fed into mainline over several release cycles, always watching out for regression reports. So, the problem is known, but the engineers working on PCI code in the kernel are given higher priority stuff to work on by their employers, hence the issue hasn't gotten the attention it deserves.
Actually I forgot to mention there's another solution: A PCIe feature called Flattening Portal Bridge (PCIe Base Spec r6.0 section 6.26). That was introduced with PCIe 5.0. It's more likely that FPB support is added in mainline than the pause/unpause feature. It's supported by recent Thunderbolt chips and it's an official feature of the PCIe standard, so companies will prefer dedicating resources to it rather than some non-standard approach.
The key takeaway, especially for the author who wants things to "just work", is that he should have used a USB external disk, instead of a Thunderbolt external disk. OSes tend to have more issues with Thunderbolt disks (such as this issue you explained in details) than with USB disks, because the latter is more common, so more corner case bugs have been eliminated.
I said linux was fragile the other day and someone replied "in what way", this post is a good answer. In the past also I had similar critiques to my own criticism of Linux.
Who knows how many total days and weeks I spent on random things like this and all the obstacles I had to overcome. Just to get secure boot working on debian, I had to overcome their block of my vpn IP on their wiki, and the sign-tool which is impossible to find and after a lot of googling found an ubuntu post suggesting a weird kernel version speicific path that worked but the builtin vbox kernel module signing thing can't find it during apt update so at each kernel update I have to manually sign vbox modules (which means making the privkey readily available and defeating the whole point but whatever), at least I made a small script that only needs my secureboot pin/pass now. And then I decided to use apparmor, which is nicer than selinux but it took weeks to lockdown two apps and have them work and I am still not confident I did it right.
Ok,ok... let me pause there because I could go on. In my current day job, I attribute my success to two things: 1) Using linux for many years and fighting these "stupid" battles 2) I learned C which made learning a lot of other stuff a lot easier. I work in security now, so when there is a linux or container/k8s related incident it is easier for me than for my colleagues. I also don't shy away from difficult technically complex incidents or problems because I am battle-hardened in the art of figuring out seemingly random problems in topics I know nothing about with the sheer power of search engines, docs and random internet posts.
When I worked my first k8s incident, I knew nothing about it. I was watching talks by google people on one window while reading docs on another and poking around in the gke node scratching my head on why the hell a k8s node is running chromeos and everything is readonly. But all of that is a piece of cake. Try random browser crashes because weird grsec/pax patches (before they closed it off) that were messing with jit or untangling a dependency mess on a gentoo install neglected for years which doesn't even have a supported python version now. The brutality and fragility of Linux has given me a lot of mental muscles that has helped me immensly and it has forced me to be distrustful of software in general and learn a lot of stuff from programming languages to permission models, os architecture and gnu tools like sed,grep,awk and the like.
But yeah, I love linux so much but let's not pretend it is easy to use or user friendly. But hey, 2023 will be the year of the Linux desktop so we'll see.
A lot if *nix philosophy and mentality like "RTFM" and defaults not being a big deal I think are from an era where the ecosystem was much less complex and the userbase was much smaller. I attribute many of these pain points to that undying mindset.
Windows and Mac have their fragile points as well.
For starters, Windows is Ubuntu bug #1. (I kid).
The nice thing about Linux is it can evolve without being pulled into advertising-and-data-monetization as a business plan. In other words, society is better off with it.
I had a similar experience recently. Updated my Manjaro setup, rebooted, and was greeted with text mode. X just didn't load. 1 hour of reading logfiles and pondering about why the kernel module wouldn't load, it turns out I needed to add an obscure boot parameter (I think it was something like "ibp=off") to my kernel command line to make the nvidia module load again.
Easy solution if you know how to solve it, 1 hour searching for that solution, and about 0% chance of that knowledge ever being useful again in the future.
In the end I was still satisfied because at least I learned something (no matter if it's useful or not), and I was under no pressure to get that particular Linux system working again (I could still dual-boot Windows for example).
Anymore these days if it only takes me an hour to wade through all the reinstall/switch distro garbage to fix some obscure nonsense problem I count it as a win.
I had a similar experience with a workplace machine. It worked flawlessly. But, sometimes, I went to make myself coffee or to the bathroom, and when I was back, the system just never woke up from sleep.
I try setting the machine to sleep and manually waking it up. No problem.
Later, I spent some time watching a long youtube video, then I opened the terminal and then the OS crashed.
Dmesg? It showed nothing
But, sometimes, when I tried to launch the terminal, I tried running htop and then the OS hanged. I had the feeling that it was something HD related.
I restarted the machine, updated the kernel, asked the forums, everything. No answer.
It was my work machine. They let me install Linux but I couldn't spend so much time with the OS. I need to have work done. Otherwise I need to bail and go back to Windows (ugh).
I was about to delete Linux from the laptop, but I had an idea: The machine was a Thinkpad T1. I looked on the Arch Wiki about compatibility with that laptop. If the problem came from an incompatibility with the hardware, it will surely show up there. The machine showed up in a list and according to the wiki, there's nothing related to a crash or a freeze.
Then, I looked up on lshw if there was any piece of hardware that was different of what the Thinkpad has by defaults.
The result? A Kingston 1TB SSD. I googled "Linux Kingston ssd lock up", "Linux Kingston ssd crash".
It turns out, some Kingston SSDs don't support all the deep sleep levels of energy saving. I needed to switch some off with a kernel parameter.
This is one of the benefits of being "obscure in only one area at a time" - just like you shouldn't break more than one law at a time, heh.
Linux is a relatively obscure OS, but you were on popular hardware with a popular SSD which helped increase the chance that someone else had run into a similar issue.
I had this issue after I built my first new machine in nearly 8 years.
I forget what I googled, but I essentially found a forum post almost immediately that explained the reason for the ibp=off, something to do with an intel security issue, caching, and the actual likelyhood of it being a security risk on a personal machine. The conclusion was basically "its enabled by default because its a good idea, but not really needed for most use-cases". Away I went disabling it, somewhat understanding why it was there.
But I've also been an arch user for years, and one thing I'm accustomed to is when the bleeding edge breaks something, other bleeding edge users are already discussing it. The overall community documentation on issues is exhaustive. If you have an obscure issue in Windows and search the error, you get windows support forums with official support asking you to click the "try to fix it pwease" button and no other solution. Half the time the only fix is a reinstall.
I ended up building a new computer because my old machine's windows install got itself in a state where it would fail to login after an update, yet constantly tried to apply that update after I'd revert it. No solutions anywhere online, no way to stop windows from trying to apply the ill-fated update. Just a broken install. I figured if I was going to spend hours re-installing and reconfiguring windows, I might as well get new hardware.
That doc string raises so many questions. First, it says minimum which to me implies that in some cases larger value is used, but no clue when. Secondly, why is the default 1 and what is the allowed range of values? Being 1 implies to me that there is some cost associated with the reservations, otherwise the default would be much higher? Is the 0x33 from the article completely random, would 2 worked just as well? What are the implications of using high value here?
What's the approach used by OSes that "just work" for things like this? Is this due to the more monolithic kernel of Linux making more things required to be known up front than e.g. in Windows?
Is there one? I know that unplugging a Thunderbolt peer will crash my MacBook Pro (bridgeOS, not macOS, panics). Disappearing buses is an edge case that is little-tested on most operating systems.
Hot-plugging Thunderbolt devices is hardly an edge-case on Macs, it's a heavily advertised feature.
I had about weekly kernel panics or machine freezes (would not wake from sleep) while unplugging my Thunderbolt dock (with displays and lots of devices) all throughout the USB-C Intel Mac era, but they all went away when I got an M1 Pro machine, so I wonder how much is down to OS design vs drivers vs hardware (vs how specific hardware influences driver design).
The M1 lacks the T-series coprocessor altogether and all its functions are inside the main SoC. Whether that means that bridgeOS still runs on non-architectural cores inside the SoC, or its responsibilities have been rolled into macOS, I have no idea. I do know that only my T2-having MacBook suffers from these panics.
- Most OSes do a full dhcp look up when they connect to a network even if they have connected to the network before. Wifi saved networks is a good example of a network where you have some historical information on the connection
- MacOs however keeps track of the IP addresses that it saw for each of the networks it has connected to recently. If it sees a network it's been on before, it first tries to just use the old IP address. This is under the assumption that the lease is still tied to the user's laptop.
- In the best case, the laptop gets a working IP very quickly and in the worst case, you just do dhcp again
- From a user's perspective, if they walk into a meeting with a bunch of folks with non Mac laptops, it will seem like the Mac connects much faster than everyone else's machine
When I read this story, the author pointed out that many people say "Macs just feel like they work better!" and used this as an example. Granted, this partly comes from owning the ENTIRE stack from hardware to drivers to OS etc which is something only Mac can do.
IIRC it does, and otherwise throws out (or used to) an ARP check (or something like that) to see if any one on the local link is using the IP. A properly behaved DHCP server would not hand the IP again to someone else if the lease hasn't expired.
> I spent several hours fixing a problem and I learned next to nothing in the process. This trick is unlikely to be useful again. By the time I encounter something similar, it is likely I will have forgotten about the solution.
This is why it is important to keep a personal knowledge base/documentation. Mine is full of things I'll probably never encounter again, but I know it may be useful one day or another.
Also, it's not like OP haven't learnt about kernel parameters. Often not just the dicrete knowledge itself, but also the way of arriving at it is just as useful.
Someone should tell the author about the great lshw, it lists full details of the system board (and everything else) without having to go to a GUI display.
People posting those CPU and SSD screens shots rather than, say, some linked data that contributes to make a graph to forums has such a deleterious effect on people's ability to reason. I suppose eventually we'll end up screen scraping the screen shots.
# dmidecode 3.4
Getting SMBIOS data from sysfs.
SMBIOS 2.7 present.
Handle 0x0002, DMI type 2, 15 bytes
Base Board Information
Manufacturer: Dell Inc.
Product Name: 02##K5
Version: A01
Serial Number: /BGK####/CN#######/
Asset Tag: Not Specified
Features:
Board is a hosting board
Board is replaceable
Location In Chassis: Not Specified
Chassis Handle: 0x0003
Type: Motherboard
Contained Object Handles: 0
This. I generally have few problems with the people I work with one exception is when they start posting screenshots on Slack. If it's some gui and you can't get a good export then I understand the frustration - but this will be a screen shot of terminal.
Why? I mean do you hate the future? Did a month from the present beat you up as a child? Perhaps when you were 10 years old 2 years from now kicked sand in your face and now you're going to punish it. I don't know. But they need to get over it for everyone's sake.
In tech support, I'd frequently get screenshots of a few lines of a terminal window pasted into PowerPoint slides and Word docs — usually via some heavily compressed remote desktop-running-on-another-remote-desktop — with the information I actually needed invariably a few lines higher. My favorite was flash photos of a monitor taken with a non-smartphone from fully airgapped sites, where the turnaround for running a command and getting the output would be at least 5 minutes because the on-site user had to leave the server closet and go down a few halls to get back to a network-connected system, copy the photo off the camera to the computer, and attach it to the ticket.
Eventually I rigged up a tool to automatically pull screenshots from tickets via the ticket system's API, then raise contrast on them with imagemagick and run them through OCR. Some red error text on a black background screencapped through multiple layers of compression might as well not exist, even if it's perfectly readable to the end user, so I'd even done comparisons (that I've since unfortunately lost) of how different command-line OCR tools fared with low-contrast color text, because Tesseract wasn't always the most functional option.
Nice to see hinv finally found its way ;) I agree, those neofetch screenshots are more about desktop GUI and such. They don't cover the hardware enough.
The thing is.... You found a solution and if you wanted to understand you can always look at the kernel doc. When a similar thing happens in Windows, you are just done... Not only you have a very slim chance of not having to reinstall everything but even less understanding what is happening (ie. Probably an intern that committed something in some close source driver than will be silently fixed some day).
If you are someone who can read and understand the kernel doc then I agree that you can be more efficient in Linux.
For the vast majority of the population the response to errors is identical on both platforms: reboot, internet searches, learn to live with it, or reinstall and hope for the best.
Similar things rarely happen in Windows because Windows has a stable kernel ABI and developers can, do, and are incentivized to supply drivers for their hardware.
This occcurs every time I decided to dab into Linux. Usually I got the answer from a random search on stackoverflow and never managed to understand what happened.
But I think it's OK. I have always had an interest in system programming and that's why I wanted to dab into Linux. But system programming is not a shiny, whole smooth thing one may imagine, but is quite messy all the time. I simply got what I wanted.
I have had my share of Linux Evenings. They built my confidence when it comes to troubleshooting system stuff, and they eroded my confidence in Linux for a while. Things are incredibly stable these days compared to even half a decade ago.
The good thing is after an evening you usually find a solution.
While one some proprietary systems the solution is usually "you are fucked deal with it".
Having said that it has been litterally years since I had this kind of problem. Checking if people have issues with devices on linux distros before buying actually works really well. I just don't buy the things that don't work. Kind of like checking at the back of the box if it is <insert os of choice> compatible.
That’s where Linux burned all the bridges on being my main machine.
Nowadays, I cannot afford to take a day off to fix obscure incompatibilities like this.
The last straw to me was when I stored my closed lid xps in a bag and 3 hours later everything was smelling like burning plastic because the computer suspend suddenly stoped working. To get things worst, it happened during a long haul flight.
I seem to recall Dell saying that you should never store a suspended laptop in a laptop bag, because there are situations where it might wake up and overheat.
> I seem to recall Dell saying that you should never store a suspended laptop in a laptop bag, because there are situations where it might wake up and overheat.
Which is the stupidest thing ever. I want to see Apple use this to shame Dell in ad.
> I spent several hours fixing a problem and I learned next to nothing in the process.
This is probably true for this specific case here, but my experience with fixing stuff in Linux is actually the opposite. I learnt a lot doing so, and learnt stuff that turned out to be later useful in very unexpected spots.
Back when I was a teen and using Windows, I've spent countless hours fiddling in stuff in regedit and other atrocities and it feels like I never learnt anything useful in the long run.
Usually my go-to for "Linux problems" is "tear down the VM and start a new one", but a few days ago my Manjaro rig at home lost power, and bluetooth wouldn't work upon restart. I wracked my brain, pored through forum threads, man pages, and LFS, but nothing really helped. It looked like several different problems at once, but none of the individual fixes worked, or only worked for minutes at a time. I stepped away from the problem for a while, as one does, while I mused about the way troubleshooting works, and how my early life with Windows and now modern containerization has predisposed me to certain types of solu-- wait, I've got it! rmmod the bluetooth modules, modprobe 'em back in. Everything worked flawlessly. I'm not sure what I learned.
I've done this enough, but don't stop there as it's likely to happen again. When I resort to such a solution, I take a look at the syslogs. More often than not, something there will tell me why a simple restart of a service, module, whatever was the answer.
I had a similar problem as the article with a standard USB 3 enclosure. Two PCs, identical OS (oS Tumbleweed), same kernel version even. modprobe -r then modprobe usbstorage and it worked. An obscure error in the logs pointed to the uas module which for some reason failed to reload, enabling the enclosure to work.
Oddly, the other PC on which it worked was loading uas.
I think unless one uses Linux on daily basis it's really difficult to sink in the knowledge. I decided to install an Archlinux VM and see what happens.
I'm kinda disappointed to myself as I found out I didn't like too much trouble so I'll probably never be a good/great programmer.
I wouldn't write it off just yet, at least if you want to be a good programmer! While there might be some correlation, there's plenty of fantastic programmers who don't want the hassle and want to focus on a specific problem and just use Windows/macOS and an easy to setup/low configuration editor. One particularly great TA I had in college comes to mind...
Thanks, but I actually wanted to learn low level stuffs, or I thought I wanted. Anyway I'll see what happens. So far nothing really clicks for me but if that's it then that's it.
What types of low-level things did you want to learn?
A lot of what seem low-level in Linux are implementation-specific things. For example, how you set up wifi or how you manage your firewall. Knowledge of these things gives you less long-lived and less transferable skills than knowledge of protocols like TCP/IP which is shared by everything that is plugged to the internet. It doesn't make you a better programmer, unless these daemons and tools are what you want to write software for.
Also, your options are not only Arch Linux and Windows/Mac. There are more desktop-ready distributions, too, like Ubuntu or Fedora. Linux lets you still inspect the plumbing if you install one of those.
> What types of low-level things did you want to learn?
To be honest, I've dabbed in a lot of low level stuffs but never went deep enough to make any impact, career-wise at least. For example I completed a full course on MCU programming, completed the first half of nand2tetris, read the first few hundreds of pages of "Beginner Reverse Engineering" (basically the part that teaches one to recognize C from decompiled assembly code), and many others. My most recent low level adventure was the book "Practical Binary Analysis" which I planned to use the whole holiday to push maybe a few chapters.
But I never drilled deep enough into any of the topics. I believe I have the brain to drill at least a few more chapters deeper for any of them, but I don't have the mental power to do it. I secretly want someone to put me into some sort of prison and keep me from getting out until I completed all previous projects and learnings. But of course I need to figure out a way to deal with the problem.
Anyway, really appreciate your answer, and probably I'll still install Archlinux, play with it a few days and then lose interest -- just another failed project to spend time.
People say "Arch makes you learn how Linux really works", but I don't think that's a good way to put it.
Arch teaches you about the most boring parts of how linux works: the specific idiosyncrasies and configuration minutiae of a ton of libraries and programs (GNU coreutils, systemd, udev, mesa, glib, X11, Xlib, xdg, dbus, etc.)
Arch will usually not teach you the really interesting "low level" things about Linux: How the kernel works, how threads are created, etc.
No it doesn't. But that's fine, it's not the point of a distro to teach you about interrupts and syscalls and all that nonsense, the point of a distro is to give you software to install. That said, Gentoo does do a good job of teaching you how annoying it is to try and figure out exactly which kernel options you need to activate to get a working system. I always run out of patience before I get it working, though (yes, I know about make localmodconfig).
I'd say it teaches you how to use Linux. It's not the particular details of each config file, but the fact that there are config files, and where to look for them. By the end of an Arch install, you know at least 85% of how to manage your system, and wiki will take you to let's say 98%.
Installing Arch is much closer to system administration than programming - they may be related somewhat and attractive to similar people; but you can be a quite successful programmer and barely be able to install Ubuntu.
I know people who have written kernel-level Linux drivers who have difficulty upgrading macOS. They're separate skillsets.
I was going to say, I know a lot of programmers, maybe even most, who avoid Linux like the plague because they don't want to waste cognitive cycles on fixing their broken machines. I have found myself in this same place after a solid 12 years or so of Linux use for pretty much everything, home, work, etc. I honestly kinda want to get back into it, but there are other priorities. As long as I have access to some kind of unix-y command line from somewhere I'm good.
Thanks for sharing. I'm a bit surprised about the second paragraph but then I realize it is indeed two skillsets.
I think I'm split between career growth and hobby. My career is much closer to a sys admin/devops than a low level programmer, but my hobby probably is closer to the later. Of course it could be just my fancy about low level programming that fascinates me as after all I have never done any low level programming except some entry level MCU programming.
>I'm a bit surprised about the second paragraph but then I realize it is indeed two skillsets.
I started out my career on the sysadmin side of things before becoming a developer and that doesn't surprise me at all. Most devs I work with have little to no understanding of things like file permissions, how networking works beyond making HTTP calls with $SomeRequestLibrary in their programming language of choice, or how services/daemons work in Windows/Linux.
Some people just don't like the Linux (or Unix) way of doing things. I personally can't understand the predisposition against it, but hey, whatever works for them I guess.
For your average user it's exactly the same desktop as windows and mac : there's menus and icons, you click on stuff, there's a browser... What's this "way" that they don't like?
They don't like free, stable and fast? They don't like how it isn't going after your wallet every 5 minutes?
It's gotta be propaganda at work. It's the only explanation.
Ubuntu desktop is anything but stable. Nuke-and-pave is the only sane solution to the OS corruption issues. The GUI is more stripped down than a holocaust victim. They still haven't figured out drag and drop. And on top of that, everyone swears such-and-such distribution is actually the good one, but it never is. The desktop is in permanent demo mode. A back-burner school project that turned into a part-time hobby.
Maybe you just use it for web browsing. But for everyone else, there's Windows. Which is still crap but at least you can set an environment variable without doing a research project into the differences between .bash_profile, .bashrc, .profile, and /etc/environment. None of which have a GUI. And the best part is that none of them can ever be renamed because muh scripts would break and the entire OS would come crashing down.
I agree. Using software modifications as a competitive advantage in business does not violate free software licenses. It does, however, violate non-free licenses like GPL
I have been setting up Ubuntu for non-technical folks for a decade. Chromebooks work great too, but I cannot justify recommending them given the proprietary Google bits included. De-Googled chromeos would probably suffice for most people though.
Honestly if you have older hardware, like a couple years old most of the most popular distros are pretty stable.
Ubuntu on hardware a few years old will chug along without issues more often than not especially if you are just using it as a glorified thin client for Chrome which is an increasingly large base of users.
There are of course some gotchas with things like integrated graphics and dedicated graphics in laptops or some device drivers for peripherals like printers (it is still linux after all, year of the linux desktop any year now aha)
Not OP, but chiming in nevertheless, as I do also "set up Linux for computer-illiterate old ladies".
They all roll Debian stable with unattended_upgrades and it's an absolute joy of stability.
Not that I would use Debian stable for my personal machines: I want the latest shiniest and I want to be close to upstream to report bugs when they're fresh and easy to fix by the maintainer (yes, "I use arch btw" indeed), but for "computer-illiterate" people, stability trumps everything else.
The "computer illiterate" isn't amused by constant breaking behavior / visual changes. They want the thing to work reliably and unsurprisingly. Debian delivers this and never breaks. Once every major dist-upgrade I review changes with them, and they're good to go until next time.
- Generally, GNOME with the dash-to-panel/dash-to-dock extension-du-jour to have a left-side panel with app buttons (so, a "Ubuntu/Unity"-like look). It baffles me how stock GNOME still insists not to provide a left/bottom "dock" / task switcher as a built-in option, and force you to go to the menu every time you want to access / switch to an app, but here we are with extensions oÔ.
- That being said, a well-configured/simplified Plasma these would certainly be all well (or not, see my final paragraph below about locking things down; GNOME is less infinitely configurable than KDE/Plasma, so there's less room for user fuckup). Also I'm certainly biased towards GNOME because that's what I choose to use for my machines. Also also, I go where there are the most eyeballs (again, for stability & maximal guarantee that bugs are seen), and for now it's GNOME.
- Exception: one grandma has a particularly old laptop (x86-32 old :D) with meager RAM, so for her setup I went with MATE. I hesitated between LxQt and MATE, tried both, and MATE (at the time) seemed a tad more polished.
Finally, since I have your interest and GUIs are a subject I love ranting about, one more thing you need to do when setting up an old ladies machine, is to LOCK DOWN ALL THE THINGS YOU CAN:
- LibreOffice toolbars that can be accidentally dragged, then maybe dragged offscreen or closed? LOCK THEM.
- Etc etc, when I'm done provisioning such a machine, I spend an hour playing with it and wondering "How could someone haphazardly clicking and dragging everywhere break/mismanage this?" , and I disable/lock/hide everything I can. There is a million configurable / breakable things that we power users don't imagine being confusing to a user, because we know the features and we're precise at clicking on stuff. But to non-computerists, these things are veeeeery confusing! They'll email you with a gibberish issue description when invoked accidentally, and when it happens too often they get scared. There's potential to build a whole distribution aimed at such users, with everything properly locked down.
I couldn't check it as I run Tb beta (which the extension doesn't support last time I check), but I might give it a try next time I maintain one of these machines ..... or not:
0. They never ever need to click it to re-order. Why bother with an unneeded feature?
1. Extensions break! UserChrome.css too, but maybe less so :) , and a CSS rule is simpler/smaller in added complexity & potential for bugs than an extension.
2. Also, hiding the columns means one less bit of chrome to read/parse. Hiding stuff avoids misclicks, but also increases GUI legibility for people with bad eyesight.
what about Fedora workstation for the old-lady use case? I'm about to give my 12 year old non-technical daughter a linux laptop, and wondering on distro. I'm thinking Fedora but open to be convinced otherwise?
For your daughter tinkering with a distro, yeah Fedora sounds awesome :)
For the old ladies, no: Fedora has a short release cycle, and no LTS; not great for maximal stability. "a version of Fedora is usually supported for at least 13 months" ( https://endoflife.date/fedora ), while Debian is security-supported at least 5 years! ( https://endoflife.date/debian )
Debian's whole project architecture & release cycle is built towards being stable bedrock, I see virtually no reason to use anything else if you aim at max. stability and don't care about running old (but still secure!) software.
> I also set up Linux for computer-illiterate old ladies. They love it.
I think you're trying to say that they don't have problems with the browser, and maybe an email client. If they're computer-illiterate, they don't know enough about an operating system to have an opinion at all, other than being happy about it turning on and off when they want.
Don't mistake that for loving Linux, because it is not really praise of Linux, it is praise for a computer that works well enough to run a web browser, which is an extremely low bar.
I started out using DOS in the mid 90's to play games, used Windows 3.1, skipped over to 98SE then XP and 7.
I have used Macs before, not enough to make an impression.
I tried Linux back when I was in collage during the XP days but it always seemed to need more tweaking than my XP install and the lack of gaming kept me on Windows.
Currently I am running Linux Mint. I install the OS and go. No need to tweak or mess with command line.
I am not that interested in which OS I am running aside from the fact that I dislike telemetry and forced updates. I want the OS to get our of the way so that I can do whatever I am trying to do, Linux seems to be there now. It feels like Windows has regressed, with setting pages buried in 5 different places.
I think the issue is that frequently the problem is with a small part of a complex subsystem that you don't understand (or perhaps didn't even know existed) before something went wrong. This sort of problem is extremely time consuming to debug via "properly" learning about the system, so you end up (much like Fabien) taking a fix from somewhere without fully understanding it.
There's also a timing issue. Often when something goes wrong it's at a random time when I'm probably intending to do something else. I don't want to put off that other thing even more by taking a "slower" route to fixing the issue.
You can of course still learn a lot along the way, as you say. So, it's not all lost, but it does seem sub-optimal.
Part of it is the binary config nature of Regedit though. I can't, from first or second principles, reason about which binary key to flip in order to change the behavior I'm looking for. Was it HKLM/ffebdcaaf, or HKLM/afbedccfh? Meanwhile if, eg dns got broken on my Linux box, there's a series of config files and daemons to check in order to figure out what's broken and then to get it working again. There's no way to learn anything with Regedit other than knowing you can just Google for the name of the key to set by looking up the problem.
Eh, having worked with both systems, I'd say they're roughly equally impenetrable. For sure, the registry sucks. But at least it's uniform and scriptable. Once you know what needs to be changed, you can write a .reg file and be reasonably confident it will at least change the registry in a valid way.
On the other hand, if the solution to a problem on Linux is to change some dotfile controlling some daemon, reliably scripting it can be difficult to impossible. Did the distro put the config file somewhere weird? Is awk good enough here? What if the key I'm looking to update is found in a comment, and what is the commenting structure for this file anyway? What if the daemon rewrites its config file on exit [0]? Or has a config file with an extremely complex format [1]? Or I need to poke several /sys files in a particular order [2]?
Both systems are hard to reason about, especially if you don't know them. But Linux isn't easy to approach for the first time, and there are advantages to the way Windows does things.
Usually the adoption and uniformity as well as the generally higher quality of Windows, in addition to the availability of good debugging tools (which work) makes troubleshooting easier.
I recently had an OpenGL related issue on Linux, I googled the error message and got 1 search result. Now I can speculate, is my program wrong? Or is it the Nvidia driver, perhaps Xorg? Did the Ubuntu devs configure something wrong etc.
Why won't Nsight or Renderman work on my machine?
Windows has by contrast a significantly larger userbase, an architecture that's set in stone, meaning I can find relevant answers from a decade ago, and there's thankfully no Windows 'distributions' so the issue I face is likely to appear on any person's machine.
Yes, I remember, even up until very recently, having to google help on Windows. You'd get webpages full of adverts with a heading '12 ways to fix Win10 freezing during upgrade bug!'. And the first two would be something like 'switch it off and on again', 'try again', 'reconnect to your wifi'.
I always felt I could dive deeper with linux problems _if I wanted to_, and that weirdly gives me some confidence that I can fix it.
And after you scroll past the obvious solutions, "Install our Fix-O-Matic software for $29.99!" because the page is actually an advertisement cloaked as a help page.
> but my experience with fixing stuff in Linux is actually the opposite. I learnt a lot doing so, and learnt stuff that turned out to be later useful in very unexpected spots.
Same, in fact it's how I fell ass-backwards into my career path.
I almost prepped myself up this Friday evening for a solo Debian reinstall party to solve an extremely slow reading/writing on internal hdd/sdd problem until I accidentally realized the problem disappeared once I had removed my external disk from the docking station. Went from 2mb/s to 2gb/s r. and 800mb/s w.
> I spent several hours fixing a problem and I learned next to nothing in the process. This trick is unlikely to be useful again. By the time I encounter something similar, it is likely I will have forgotten about the solution.
No segway, I've posted a bit of a discussion above. Not all that interesting unfortunately. The error message was obscure but the problem space was pretty small so I did mostly the same thing as Fabian and searched online for related terms to PCIe hotplugging and PCIe address allocation.
Occasional issues like these is why I continue to run Windows even though Microsoft has been pulling off all sorts of shenanigans with telemetry, broken file manager / start menu, ads etc.
I really want to move to Linux but unless my laptop manufacturer provides support, its never going to happen. I don't want to think my OS when buying a hardware accessary or a software product.
A laptop's a tool and Windows still provides the most support.
For takeaway 2, I've found using NixOS lately to be good at keeping myself disciplined about documenting the odd little hacks I've added to fix an issue. Like in this case, I'd have to add something to my boot.loader.grub.extraConfig setting, comment it and document it with a hopefully-useful commit message so that if I encounter something similar in future, I can at least look at those bits of documentation and hopefully connect the two.
+1 on this. I use to consider those Linux evenings as a waste of time. But with every bit of NixOS tracked within git with some history and context, I now think of it like an investment for the next 50 years, which has way more chances to pay back
I don't use NixOS but I have a similar documenting approach to all my OS and $HOME config files. Every customized file / override is checked in to a git repo, and there's an `install.sh` that takes each such file / directory and copies / symlinks it from the repo to its target location. Basically the same concept as dotfiles, but also for system files. I've restored a couple of machines from OS reinstall to full readiness this way.
I used to hear "Linux is only free if you don't value your time." - this article seems to validate that this is still the case. Am I getting the wrong impression?
I am afraid your comment does not encourage discussion. You can try justifying your assertions. Otherwise we just talking about feelings. I find the open source world gives me hope on humanity, in opposition to the sensation i get from Mucrosoft or Apple. I find learning the command line rewarding, that is the strenght of Linux IMO
I use it everyday. It's beyond inferior. Terminal is still needed for a lot of things that should have a GUI. Gaming support still inferior. Applications that only exist for Windows and/or MacOS. Linux had it's chance on desktop. Especially during Windows 8 trash era. It blew it. It's game over.
Personally, I've been riding the linux struggle bus for years in my personal time. It really hasn't been a struggle, but weird issue's I've dealt with during my "Linux evenings" has made obscure struggles at my day job far easier to debug and deal with, and overall has made me a better engineer because I know how my tools work and I can use them more effectively.
It's a whole lot more fun learning about kernel drivers, systemd, networking drivers, etc when you're personally invested in tweaking your machine just right. I much rather deal with a Linux issue for an hour than spend an hour on leetcode.
I've had linux evenings, windows evenings, macOS evenings, hardware evenings, software evenings, house evenings.
Anything you use has a chance of failure and on the whole I feel Linux has taken less time to do what I want to do with it than other similar options.
Thought I started using macOS at home because I got tired of dealing with Linux desktop shit, so take that as you will.
> “If you’ve ever read a mystery story you know that a detective never works so hard as when he’s on vacation. He’s like the postman who goes for a long walk on his day off.”
It really depends upon what you are doing with your machine.
If you're dealing with new hardware, situations like the one described in the article may pop up since vendors will focus their testing on Windows (and possibly macOS) so there is a good chance that it will work on the commercial operating systems but not the open source ones. That is going to be especially true to more exotic hardware since there will also be less testing by the open source community.
On the other hand, I find managing a Linux system significantly more time efficient. Some of it is because of the nature of open source. For example: installing, updating, and removing software is much easier since the licensing model allows distribution maintainers to create a universal software management tool. In other cases, it is simply because of the approaches typically taken by open source developers. For example: it is usually easy to copy configuration files from one system to another.
100%. A similarly snarky corollary could be that Windows is not free, and Microsoft still shafts you regardless. From what I gather, is that if you'd like the least sucky UX while not leaving the designated path, Apple is the way to go. Otherwise, you're going to have "X Evenings". And even Apple land, despite the fame, is not without its weird incompatibilities, dongles, random issues and such.
To me, a lot of the frustrations boiled down to familiarity. I used to be touchy around Linux, because it was weird to me all the time, switching from a decade plus of Windows experience. Whatever broke with Linux, it was a Linux problem, and whatever broke in Windows, it was a stupid computer problem. Do you see the bias? Now that I have the user experience, Linux issues are familiar, and whenever there's anything that's out of place, I know where to look, what to search. And Windows, with its penchant to reorganize the Control Panel every release, seems like a maze to me, where I get more frustrated at every turn.
At the end of the day, it's pick your poison really.
> After all, if I elect to use Linux, a niche market by all means, shouldn't I be ready for these kinds of quests?
Yes and no. I think if our only tools are are Google (well, now Kagi for me), Stack overflow et al., and the sites that hold quality content quick to the point, you'll be spending a lot of time on the info finding and not the fixing.
I think it requires a a lot of information organization tools to continue to keep up with it. Or sink more time into info finding. Or just memorize everything if you have a brain for that
329 comments
[ 3.1 ms ] story [ 272 ms ] threadhttps://lwn.net/Articles/767885/
Contribution does not necessarily mean code. It can be documentation, design, UX, sharing information, or just working getting people familiar with Linux.
My story, I bought a new widget, a gaming wheel a few years back, and it did not work on my Windows machine, I even reinstalled Windows, installed the drivers from disk it did not work. I send the thing back and report it broken and the guys call me to report that works perfectly. In the end I bought a different model that worked both on Windows and Linux.
So a gadget with official Windows support did not work on my machine, even after I wasted my time reinstalling Windows just in case but worked fine for some support people.
I had a diffrent experience with a USB WifFi antenna , it come with a mini CD with drivers but my PC had no CD Drive, there was no online source for that no name brnd.
I plugged it on a Linux machine and it worked, then I done a lsusb and found the real chip powering the device, then Googled for that I found a compatible Windows driver on a drivers website and I fixed it for Windows machine.
Linux has problems, but install a LTS distro on compatible hardware and you should not have issues for a few years.
To balance things, my latest bad experience in KDE was when Kwin crashed and refused to enable compositing again printing a vague reason in the logs, I found using Google that KWin put an isOPenGLSafe=false in soem log file and refused to start compositing but for some reason (maybe is a valid one) was incapable to print also that "I refuse to start compositing because of this setting - lesson for us devs, when we put stuff in log messages, put as much info as possible
And following up by silently escalating recently-solved problems beyond the reach of posted workarounds.
Just in case the doubling down does not proceed as expected.
I've supported both professionally, and no, you don't. I blame the claim on a lot of people using commercial operating systems feeling a bit guilty, like they're supposed to be on Linux to be a real developer. They respond by criticizing an OS that they don't really use for the problems that they imagine happen all the time. Instead, what's happening is that they, personally, always run into problems trying to figure out why something won't work in prod, or trying to get their VMs to work like the tutorial, and they assume that people who use Linux as a daily driver run into problems at that rate. They never pay attention to Linux unless something critical has already broken.
Also, whenever they decide that they're going to try Linux again to see if it's ready for them yet, they always choose Arch (it used to be Gentoo) or the latest trendy distro that has a MacOS aping desktop. Just install Debian, it's easy.
That isn't a just Linux thing. You can easily fork-bomb (or equivalent) Windows/iOS/other and so forth, especially (though not only) if running as a privileged user.
> And then non-obvious issues that just "appear" out of nowhere
That is definitely not something that I've never seen when using Windows! Where it has happened to me under Linux it has been eventually traced to a hardware issue or a bad update (the latter I've experienced on both those OSs over the years and the former will affect everything).
I've crashed DWM with WSL before, by doing something completely unrelated to Windows.
What happens is you start getting the solitaire effect because suddenly no windows have graphics buffers anymore
>That is definitely not something that I've never seen when using Windows!
Case in point: my laptop (running the Windows 10 it came with) recently stopped hibernating properly, well it hibernates OK but half the time when it wakes up the screen does not turn on, and this evening it has decided that it doesn't want to be asleep while plugged in. If I tell it to sleep (through power key or start menu) while plugged in it does very temporarily and then returns to the login screen. If I tell it to sleep when running on battery it does but immediately wakes up once power is connected.
While Linux distros are far from free from random problems at times, in my experience Windows exhibits them more and tends to be harder to diagnose because more is hidden.
The solution is running a userspace out-of-memory killer, e.g. earlyoom.
The other day I changed /etc/ld.so.conf and the system would not boot—my fault. I choose the previous deployment in GRUB and I had a working system back.
I think better UX and more configurability would solve this stuff (from a friendly interface). The reason desktop/distro people won't do that is because it is considered bad UX practice to have too many decisions for the user. But imo, a Linux user would be an exception. In an ideal world, whoever decided to disable the boot flag in this case should have provided an easy to access distro/de setting to flip it back on.
Mind you I have my grub set to boot into windows by default so that if there's a power outage, my game streaming and backup setup, which is on my windows partition for now, will relaunch if I'm traveling or something. Yet if it had booted into that stupid splash screen, Steam and etc won't have been able to launch, and I'd have been SOL!
I hate windows!!!!! I can't wait to get EVERYTHING onto linux. I have a todo to see about using proton compatibility for desktop gaming, it works great on steam deck. After that the only remaining thing is ableton, and I'll have been completely freed from windows forever!
Because the amount of time spent on unwanted Windows things is radically less than the amount of time spent on Linux evenings.
Windows does by and large just work. Every OS has warts and bugs. I want to spend the absolute minimum time on them.
Linux is getting better and may not require too many Linux evenings these days. But that’s really only true if you’ve burned hundreds of hours dealing with increasingly obscure Linux errors.
It’s not too hard to understand why different people prefer Linux, Mac, or even Windows. They all have pros and cons.
I also have a somewhat interesting usecase that doesn't let me switch to Mac (not that I am keen to). If I buy a Mac, I will have to switch my phone to iPhone too because integration with Android isn't nearly as good. However I _must_ have a dual sim phone (which is fairly easy with Android) and there aren't any dual sim models of iPhone.
Aren't phones with an eSIM + regular SIM effectively dual-SIM? I'm pretty sure iphones have those.
Docs for SIM + eSIM: https://support.apple.com/en-gb/guide/iphone/iph9c5776d3c/io...
Docs for dual physical SIM: https://support.apple.com/en-us/HT209086
Now my phone is still confused after restoring from backup and cannot see the eSIM. I’ve been filing feedbacks and radars to no avail. If I was on Android I’d have just rooted it and deleted the offending (mis)configuration file already!
You can't access the whole filesystem of a running iDevice with it, but you can access the whole filesystem of the backup. So I suspect it might be possible for you to clean-up the backup offline & then restore it. (At a minimum it should enable you to extract the valuable contents out of the backup and manually restore it on top of a clean iOS install.)
I've used it with some success to extract info from the photos database. I just wish they had a consumer-facing (read: more affordable/perpetually licensed) version of their CLI tool.
[1]: https://imazing.com/
Also, I like the flexibility of using the physical SIM because I can easily use them with both smart and feature phones without issues.
I use iPhone + Mac, but I don’t remember any hiccups when it was android + Mac. Most of my interaction between the devices is pretty indirect anyway (photos are shared through google cloud, etc).
[0]: https://syncthing.net/
Mika Westerberg is constantly fine-tuning the allocation of PCI resources in the Linux kernel to avoid such scenarios. Some recent patches:
https://lore.kernel.org/linux-pci/20220905080232.36087-1-mik...
https://lore.kernel.org/linux-pci/20221130112221.66612-1-mik...
On macOS, it's possible to pause the PCI bus, reallocate resources and unpause the bus:
https://developer.apple.com/library/archive/documentation/Ha... (search for "Supporting PCIe Pause")
We don't have that on Linux unfortunately, so we depend on getting the initial resource allocation right.
Sergei Miroshnichenko has worked on such a reallocation feature for Linux but it hasn't been accepted into mainline yet and he hasn't posted a new version of his patches for almost two years, so the effort seems stalled:
https://lore.kernel.org/linux-pci/20201218174011.340514-1-s....
The patch for pausing and unpausing seems quite reasonable, except that it does require driver support (unsurprising - you’re literally reallocating the resources used by the driver!). I suppose if you had at least a few movable devices then you should be ok in the event of a hotplug event, so you’d have to hope that enough drivers bother to support the feature.
I wonder what is necessary to get people to care about the patch enough to fix it up and mainline it? I suppose the problem it fixes is still niche enough that not so many people are clamoring for the fix.
Patches come both from vendors and users experiencing an issue. Vendors take care of most things, but for esoteric problems you might only have a handful of people experiencing it. The vendor is unlikely to care, so if you do not write the patch or pay someone to do it, who will?
Still better than the competition, where such problems will never be fixed unless it generates sufficient bad PR...
> "Still better than the competition, where such problems will never be fixed unless it generates sufficient bad PR..."
The competition comes under "pay someone else to do it".
I'm sure there's an amount of money you can throw at Microsoft to get something done. I don't know how much it is, but I'm guessing it's more than it would cost to find a vendor to do it for Linux.
The serious answer to " What is the point in having all of the drivers be open sourced and mainlined if we're not willing to fix them to support this?" is "There are many points to this, but one of them is that it's possible to fix them to support it, if someone wants to put in the effort. It's worth something that it's theoretically possible if you really need it, even if no one else has done it yet.".
The answer "You can do it yourself" is meant to help them understand "Anyone can do it, someone needs to step up to the plate. But it's also true that it costs resources. If you're wondering why no one else has done it yet, it's the same reason you haven't done it yet".
Ah, this argument again. Yeah, the maintainers owe you nothing, as they have already worked their asses off to give you something for free. You have the right to make polite bug reports and discuss fixes, but no one is entitled to force volunteers to do work.
But, that is not the same thing as everyone having to fix their own shit. 100 million users does not need 100 million developers.
What matters is that the users that have issues can fix issues, and if the issue affects enough people, it will eventually affect someone able and willing to fix it. That is why open source works, but it requires that some people put in the effort, and many learn to do it exactly when they get annoyed by a bug.
So yeah, if you are not willing to wait for someone else to come around and volunteer to fix it, patch it yourself or pay someone else to do it. That's how the system works, regardless of how demeaning you feel this is to non-developers or developers that feel that their time is more valuable than that of others.
> The competition comes under "pay someone else to do it".
Sure, if you have enough money to convince Apple or Microsoft specifically to prioritize fixing your issue (which may be in an unsupported or deprecated configuration) above what else they were doing, which would cost a whole lot more than just engineer and manager time. You have no alternative, as only your specific vendor can make the fix. Realistically speaking, if you had that kind of money you probably already have employed engineers that you could get to fix your open source issues for you and would not be arguing on hacker news about the need to write patches.
For open source, you don't have to convince anyone in particular. Can't convince the first person you try with money? Just ask the next person, anyone can submit the patch.
The parent comment by AnIdiotOnTheNet was not in the context of bug reports filed to maintainers, or insulting anyone, or demanding anything specific. The parent of that said that the patch looked good "but" would need driver support, perhaps suggesting that's a showstopper. AnIdiotOnTheNet asked what the point of having open source drivers is if they can't be fixed, or charitably steelmanned read as "the drivers are open so they can be fixed to work with the patch". Blueflow's reply "you are free to submit a patch" is technically correct, but low value - few people on HN aren't aware of that. The following "or request a refund" is conversation ending, "fix it or shut up, stop talking about it".
It's a common reply format on internet Linux discussions which is closer to 'silence wrongthink' or 'cancel culture' than tech discussion.
> "So yeah, if you are not willing to wait for someone else to come around and volunteer to fix it, patch it yourself or pay someone else to do it."
Or ... talk about it, rant about it, 'raise awareness', exercise freedom of speech. "Patch it or shut up" aren't the only options. And look, dkozel replied with a long and technically detailed comment[1] and didn't need anyone jumping in to silence unapproved questions.
[1] https://news.ycombinator.com/item?id=34016094
Waiting patiently and politely reporting bugs is a fine strategy: If a problem affects enough people, it will eventually affect a developer capable and willing to fix it. If you want it go faster, you will have to get your hands dirty - many contributors acquired the skills exactly because they were annoyed by an issue and decided to fix it.
Why is it so much more important to put someone in their place and win internet points with ad-homs in the "community" which supposedly values freedom?
You two are just rude. No amount of freedom forces other people to bear with that. And if you think its not rude, still, the world is large enough to avoid each other.
That is the least charitable interpretation of it, and I think not at all what it actually says.A much better reading of it is, paraphrased:
"The PCI-e patch is nice, but it would be a dealbreaker waiting on driver support."
"The drivers are open source and checked into the same tree, so there's no dealbreaker there in waiting for vendors or coordinating with third party organisations and their release schedules {and that's the point of desiring open source drivers, so the system isn't hobbled by binary blob drivers and vendor release schedules}".
Very poor choice of words. If the deal is bad, request a refund!
I understand what you are trying to say, but i think that's just entitlement.
Just accept that, as a non-contributing OSS user, you have zero leverage over which features other people pour their energy into. If you do, that's a charitable exception and happens at the generosity of the one doing the work for you.
Edit: Let me quote the licensing terms that you agreed to and gave you permission to use the linux kernel at all:
The "deal" in question was imaginary person A offering patches to the kernel to fix the articles's PCIe allocation, and the Kernel maintainers hypothetically refusing the patches on the grounds that it would break compatibility with drivers and so it cannot happen. Then the comment that the drivers could be updated to match, so the patch could hypothetically happen. There is NO entitlement anywhere in this imaginary scenario, there is no demand for anyone to write such patch, no expectation that someone get right on updating the drivers, no insinuation that someone owes a review of such a patch, nothing that you are so het up about has happened or been implied to happen, been demanded, expected, requested, suggested or implied.
> "Just accept that, as a non-contributing OSS user, you have zero leverage over which features other people pour their energy into."
Where did you come up with the idea that I am a non-contributing OSS user? Because it drives your superiority fantasy, I suspect, where "putdowns of the inferior" are the order of the day.
By your comments, it would be appropriate to ad-hom you now for your apparent entitlement to controling other people's speech about OSS, right?
[1] https://gist.github.com/richhickey/1563cddea1002958f96e7ba95...
And if thats "controling other people's speech" to you, then yes, your attitude is the problem. Realistically, i'm just some random dude on this forum, telling you off is the worst thing i can do to you.
Enjoy your refund.
Multiple times now I have pointed out that I have not shown the behaviours you are accusing me of. The difference of who has intentions to change is that you are wrong.
> “i'm just some random dude on this forum, telling you of”
You are doing so like a teacher with the wrong understanding, and despite being corrected you are intent on making sure someone gets told off whether it’s appropriate or not.
> Enjoy your refund.
You are free to link to the place in this thread where I personally said I was unsatisfied with some piece of software, or unsatisfied with the work someone was doing on it, or in any way mentioned desiring a refund or expecting more work? I think you won't be able to find such a place, so your 'clever comment' falls flat.
Open source projects rely on volunteers mostly so it isn’t like there’s some outside force to appeal to. If nobody volunteers a solution, then it isn’t important enough to solve. The point is that, if it were important enough to fix, anybody with the requisite skills could do so.
With open source and mainlined drivers, it's very difficult to change all the drivers and ensure they work.
Without open source and mainlined drivers, it becomes impossible.
Mainline drivers can move gradually. If they want to be nice for out-of-tree drivers then they can describe a timeline for deprecating and removing the support for non-reallocating drivers.
This would require the kernel being able to either update its own command line somehow, or having some permanent storage somewhere it could store it.
Or this could all be done by systemd - detect that message, increase the resource, next reboot will fix it.
That would need help from userland, which is not involved in the early boot process.
You could I guess change kernel init parameters and save that in your boot loader, but that is very hackish.
Actually I forgot to mention there's another solution: A PCIe feature called Flattening Portal Bridge (PCIe Base Spec r6.0 section 6.26). That was introduced with PCIe 5.0. It's more likely that FPB support is added in mainline than the pause/unpause feature. It's supported by recent Thunderbolt chips and it's an official feature of the PCIe standard, so companies will prefer dedicating resources to it rather than some non-standard approach.
I guess this is sorry for those niche hardware use cases.
Isn't FPB into PCIe 4.0? (I am not a SIG member, cannot read the specs).
Who knows how many total days and weeks I spent on random things like this and all the obstacles I had to overcome. Just to get secure boot working on debian, I had to overcome their block of my vpn IP on their wiki, and the sign-tool which is impossible to find and after a lot of googling found an ubuntu post suggesting a weird kernel version speicific path that worked but the builtin vbox kernel module signing thing can't find it during apt update so at each kernel update I have to manually sign vbox modules (which means making the privkey readily available and defeating the whole point but whatever), at least I made a small script that only needs my secureboot pin/pass now. And then I decided to use apparmor, which is nicer than selinux but it took weeks to lockdown two apps and have them work and I am still not confident I did it right.
Ok,ok... let me pause there because I could go on. In my current day job, I attribute my success to two things: 1) Using linux for many years and fighting these "stupid" battles 2) I learned C which made learning a lot of other stuff a lot easier. I work in security now, so when there is a linux or container/k8s related incident it is easier for me than for my colleagues. I also don't shy away from difficult technically complex incidents or problems because I am battle-hardened in the art of figuring out seemingly random problems in topics I know nothing about with the sheer power of search engines, docs and random internet posts.
When I worked my first k8s incident, I knew nothing about it. I was watching talks by google people on one window while reading docs on another and poking around in the gke node scratching my head on why the hell a k8s node is running chromeos and everything is readonly. But all of that is a piece of cake. Try random browser crashes because weird grsec/pax patches (before they closed it off) that were messing with jit or untangling a dependency mess on a gentoo install neglected for years which doesn't even have a supported python version now. The brutality and fragility of Linux has given me a lot of mental muscles that has helped me immensly and it has forced me to be distrustful of software in general and learn a lot of stuff from programming languages to permission models, os architecture and gnu tools like sed,grep,awk and the like.
But yeah, I love linux so much but let's not pretend it is easy to use or user friendly. But hey, 2023 will be the year of the Linux desktop so we'll see.
A lot if *nix philosophy and mentality like "RTFM" and defaults not being a big deal I think are from an era where the ecosystem was much less complex and the userbase was much smaller. I attribute many of these pain points to that undying mindset.
For starters, Windows is Ubuntu bug #1. (I kid).
The nice thing about Linux is it can evolve without being pulled into advertising-and-data-monetization as a business plan. In other words, society is better off with it.
Easy solution if you know how to solve it, 1 hour searching for that solution, and about 0% chance of that knowledge ever being useful again in the future.
In the end I was still satisfied because at least I learned something (no matter if it's useful or not), and I was under no pressure to get that particular Linux system working again (I could still dual-boot Windows for example).
I try setting the machine to sleep and manually waking it up. No problem.
Later, I spent some time watching a long youtube video, then I opened the terminal and then the OS crashed.
Dmesg? It showed nothing
But, sometimes, when I tried to launch the terminal, I tried running htop and then the OS hanged. I had the feeling that it was something HD related.
I restarted the machine, updated the kernel, asked the forums, everything. No answer.
It was my work machine. They let me install Linux but I couldn't spend so much time with the OS. I need to have work done. Otherwise I need to bail and go back to Windows (ugh).
I was about to delete Linux from the laptop, but I had an idea: The machine was a Thinkpad T1. I looked on the Arch Wiki about compatibility with that laptop. If the problem came from an incompatibility with the hardware, it will surely show up there. The machine showed up in a list and according to the wiki, there's nothing related to a crash or a freeze.
Then, I looked up on lshw if there was any piece of hardware that was different of what the Thinkpad has by defaults.
The result? A Kingston 1TB SSD. I googled "Linux Kingston ssd lock up", "Linux Kingston ssd crash".
It turns out, some Kingston SSDs don't support all the deep sleep levels of energy saving. I needed to switch some off with a kernel parameter.
I never had any problems with that machine again.
Linux is a relatively obscure OS, but you were on popular hardware with a popular SSD which helped increase the chance that someone else had run into a similar issue.
I forget what I googled, but I essentially found a forum post almost immediately that explained the reason for the ibp=off, something to do with an intel security issue, caching, and the actual likelyhood of it being a security risk on a personal machine. The conclusion was basically "its enabled by default because its a good idea, but not really needed for most use-cases". Away I went disabling it, somewhat understanding why it was there.
But I've also been an arch user for years, and one thing I'm accustomed to is when the bleeding edge breaks something, other bleeding edge users are already discussing it. The overall community documentation on issues is exhaustive. If you have an obscure issue in Windows and search the error, you get windows support forums with official support asking you to click the "try to fix it pwease" button and no other solution. Half the time the only fix is a reinstall.
I ended up building a new computer because my old machine's windows install got itself in a state where it would fail to login after an update, yet constantly tried to apply that update after I'd revert it. No solutions anywhere online, no way to stop windows from trying to apply the ill-fated update. Just a broken install. I figured if I was going to spend hours re-installing and reconfiguring windows, I might as well get new hardware.
I had about weekly kernel panics or machine freezes (would not wake from sleep) while unplugging my Thunderbolt dock (with displays and lots of devices) all throughout the USB-C Intel Mac era, but they all went away when I got an M1 Pro machine, so I wonder how much is down to OS design vs drivers vs hardware (vs how specific hardware influences driver design).
https://en.wikipedia.org/wiki/BridgeOS says it runs the Touch Bar.
- Most OSes do a full dhcp look up when they connect to a network even if they have connected to the network before. Wifi saved networks is a good example of a network where you have some historical information on the connection
- MacOs however keeps track of the IP addresses that it saw for each of the networks it has connected to recently. If it sees a network it's been on before, it first tries to just use the old IP address. This is under the assumption that the lease is still tied to the user's laptop.
- In the best case, the laptop gets a working IP very quickly and in the worst case, you just do dhcp again
- From a user's perspective, if they walk into a meeting with a bunch of folks with non Mac laptops, it will seem like the Mac connects much faster than everyone else's machine
When I read this story, the author pointed out that many people say "Macs just feel like they work better!" and used this as an example. Granted, this partly comes from owning the ENTIRE stack from hardware to drivers to OS etc which is something only Mac can do.
I assume MacOS actually only re-uses IPs if it sees the lease hasn't already expired but it might be dumber than that.
One of the common issues with this is that home routers don't usually persist leases across power cycles.
> I spent several hours fixing a problem and I learned next to nothing in the process. This trick is unlikely to be useful again. By the time I encounter something similar, it is likely I will have forgotten about the solution.
This is why it is important to keep a personal knowledge base/documentation. Mine is full of things I'll probably never encounter again, but I know it may be useful one day or another.
Why? I mean do you hate the future? Did a month from the present beat you up as a child? Perhaps when you were 10 years old 2 years from now kicked sand in your face and now you're going to punish it. I don't know. But they need to get over it for everyone's sake.
Eventually I rigged up a tool to automatically pull screenshots from tickets via the ticket system's API, then raise contrast on them with imagemagick and run them through OCR. Some red error text on a black background screencapped through multiple layers of compression might as well not exist, even if it's perfectly readable to the end user, so I'd even done comparisons (that I've since unfortunately lost) of how different command-line OCR tools fared with low-contrast color text, because Tesseract wasn't always the most functional option.
For the vast majority of the population the response to errors is identical on both platforms: reboot, internet searches, learn to live with it, or reinstall and hope for the best.
But I think it's OK. I have always had an interest in system programming and that's why I wanted to dab into Linux. But system programming is not a shiny, whole smooth thing one may imagine, but is quite messy all the time. I simply got what I wanted.
While one some proprietary systems the solution is usually "you are fucked deal with it".
Having said that it has been litterally years since I had this kind of problem. Checking if people have issues with devices on linux distros before buying actually works really well. I just don't buy the things that don't work. Kind of like checking at the back of the box if it is <insert os of choice> compatible.
Nowadays, I cannot afford to take a day off to fix obscure incompatibilities like this.
The last straw to me was when I stored my closed lid xps in a bag and 3 hours later everything was smelling like burning plastic because the computer suspend suddenly stoped working. To get things worst, it happened during a long haul flight.
https://www.dell.com/community/XPS/FAQ-Modern-Standby/td-p/7...
Which is the stupidest thing ever. I want to see Apple use this to shame Dell in ad.
This is probably true for this specific case here, but my experience with fixing stuff in Linux is actually the opposite. I learnt a lot doing so, and learnt stuff that turned out to be later useful in very unexpected spots.
Back when I was a teen and using Windows, I've spent countless hours fiddling in stuff in regedit and other atrocities and it feels like I never learnt anything useful in the long run.
*sigh*
"Have you tried turning it off and on again?"
I had a similar problem as the article with a standard USB 3 enclosure. Two PCs, identical OS (oS Tumbleweed), same kernel version even. modprobe -r then modprobe usbstorage and it worked. An obscure error in the logs pointed to the uas module which for some reason failed to reload, enabling the enclosure to work.
Oddly, the other PC on which it worked was loading uas.
I'm kinda disappointed to myself as I found out I didn't like too much trouble so I'll probably never be a good/great programmer.
A lot of what seem low-level in Linux are implementation-specific things. For example, how you set up wifi or how you manage your firewall. Knowledge of these things gives you less long-lived and less transferable skills than knowledge of protocols like TCP/IP which is shared by everything that is plugged to the internet. It doesn't make you a better programmer, unless these daemons and tools are what you want to write software for.
Also, your options are not only Arch Linux and Windows/Mac. There are more desktop-ready distributions, too, like Ubuntu or Fedora. Linux lets you still inspect the plumbing if you install one of those.
To be honest, I've dabbed in a lot of low level stuffs but never went deep enough to make any impact, career-wise at least. For example I completed a full course on MCU programming, completed the first half of nand2tetris, read the first few hundreds of pages of "Beginner Reverse Engineering" (basically the part that teaches one to recognize C from decompiled assembly code), and many others. My most recent low level adventure was the book "Practical Binary Analysis" which I planned to use the whole holiday to push maybe a few chapters.
But I never drilled deep enough into any of the topics. I believe I have the brain to drill at least a few more chapters deeper for any of them, but I don't have the mental power to do it. I secretly want someone to put me into some sort of prison and keep me from getting out until I completed all previous projects and learnings. But of course I need to figure out a way to deal with the problem.
Anyway, really appreciate your answer, and probably I'll still install Archlinux, play with it a few days and then lose interest -- just another failed project to spend time.
Arch teaches you about the most boring parts of how linux works: the specific idiosyncrasies and configuration minutiae of a ton of libraries and programs (GNU coreutils, systemd, udev, mesa, glib, X11, Xlib, xdg, dbus, etc.)
Arch will usually not teach you the really interesting "low level" things about Linux: How the kernel works, how threads are created, etc.
I know people who have written kernel-level Linux drivers who have difficulty upgrading macOS. They're separate skillsets.
I think I'm split between career growth and hobby. My career is much closer to a sys admin/devops than a low level programmer, but my hobby probably is closer to the later. Of course it could be just my fancy about low level programming that fascinates me as after all I have never done any low level programming except some entry level MCU programming.
I started out my career on the sysadmin side of things before becoming a developer and that doesn't surprise me at all. Most devs I work with have little to no understanding of things like file permissions, how networking works beyond making HTTP calls with $SomeRequestLibrary in their programming language of choice, or how services/daemons work in Windows/Linux.
I use Linux every day and I never touch the engine.
I also set up Linux for computer-illiterate old ladies. They love it.
They don't like free, stable and fast? They don't like how it isn't going after your wallet every 5 minutes?
It's gotta be propaganda at work. It's the only explanation.
Maybe you just use it for web browsing. But for everyone else, there's Windows. Which is still crap but at least you can set an environment variable without doing a research project into the differences between .bash_profile, .bashrc, .profile, and /etc/environment. None of which have a GUI. And the best part is that none of them can ever be renamed because muh scripts would break and the entire OS would come crashing down.
Ubuntu on hardware a few years old will chug along without issues more often than not especially if you are just using it as a glorified thin client for Chrome which is an increasingly large base of users.
There are of course some gotchas with things like integrated graphics and dedicated graphics in laptops or some device drivers for peripherals like printers (it is still linux after all, year of the linux desktop any year now aha)
They all roll Debian stable with unattended_upgrades and it's an absolute joy of stability.
Not that I would use Debian stable for my personal machines: I want the latest shiniest and I want to be close to upstream to report bugs when they're fresh and easy to fix by the maintainer (yes, "I use arch btw" indeed), but for "computer-illiterate" people, stability trumps everything else.
The "computer illiterate" isn't amused by constant breaking behavior / visual changes. They want the thing to work reliably and unsurprisingly. Debian delivers this and never breaks. Once every major dist-upgrade I review changes with them, and they're good to go until next time.
- That being said, a well-configured/simplified Plasma these would certainly be all well (or not, see my final paragraph below about locking things down; GNOME is less infinitely configurable than KDE/Plasma, so there's less room for user fuckup). Also I'm certainly biased towards GNOME because that's what I choose to use for my machines. Also also, I go where there are the most eyeballs (again, for stability & maximal guarantee that bugs are seen), and for now it's GNOME.
- Exception: one grandma has a particularly old laptop (x86-32 old :D) with meager RAM, so for her setup I went with MATE. I hesitated between LxQt and MATE, tried both, and MATE (at the time) seemed a tad more polished.
Finally, since I have your interest and GUIs are a subject I love ranting about, one more thing you need to do when setting up an old ladies machine, is to LOCK DOWN ALL THE THINGS YOU CAN:
- LibreOffice toolbars that can be accidentally dragged, then maybe dragged offscreen or closed? LOCK THEM.
- Thunderbird folder column titles that will change email ordering if accidentally clicked? HIDE THEM with userChrome.css until https://bugzilla.mozilla.org/show_bug.cgi?id=237051 is fixed.
- Etc etc, when I'm done provisioning such a machine, I spend an hour playing with it and wondering "How could someone haphazardly clicking and dragging everywhere break/mismanage this?" , and I disable/lock/hide everything I can. There is a million configurable / breakable things that we power users don't imagine being confusing to a user, because we know the features and we're precise at clicking on stuff. But to non-computerists, these things are veeeeery confusing! They'll email you with a gibberish issue description when invoked accidentally, and when it happens too often they get scared. There's potential to build a whole distribution aimed at such users, with everything properly locked down.
Might be more intuitive than locking them?
I couldn't check it as I run Tb beta (which the extension doesn't support last time I check), but I might give it a try next time I maintain one of these machines ..... or not:
0. They never ever need to click it to re-order. Why bother with an unneeded feature?
1. Extensions break! UserChrome.css too, but maybe less so :) , and a CSS rule is simpler/smaller in added complexity & potential for bugs than an extension.
2. Also, hiding the columns means one less bit of chrome to read/parse. Hiding stuff avoids misclicks, but also increases GUI legibility for people with bad eyesight.
For the old ladies, no: Fedora has a short release cycle, and no LTS; not great for maximal stability. "a version of Fedora is usually supported for at least 13 months" ( https://endoflife.date/fedora ), while Debian is security-supported at least 5 years! ( https://endoflife.date/debian )
Debian's whole project architecture & release cycle is built towards being stable bedrock, I see virtually no reason to use anything else if you aim at max. stability and don't care about running old (but still secure!) software.
I think you're trying to say that they don't have problems with the browser, and maybe an email client. If they're computer-illiterate, they don't know enough about an operating system to have an opinion at all, other than being happy about it turning on and off when they want.
Don't mistake that for loving Linux, because it is not really praise of Linux, it is praise for a computer that works well enough to run a web browser, which is an extremely low bar.
Meanwhile the latest supported versions of MacOS or Windows will not work on such a machine. Those ecosystems demand you continually buy new hardware.
I think is -is- Linux they love here.
I started out using DOS in the mid 90's to play games, used Windows 3.1, skipped over to 98SE then XP and 7.
I have used Macs before, not enough to make an impression.
I tried Linux back when I was in collage during the XP days but it always seemed to need more tweaking than my XP install and the lack of gaming kept me on Windows.
Currently I am running Linux Mint. I install the OS and go. No need to tweak or mess with command line.
I am not that interested in which OS I am running aside from the fact that I dislike telemetry and forced updates. I want the OS to get our of the way so that I can do whatever I am trying to do, Linux seems to be there now. It feels like Windows has regressed, with setting pages buried in 5 different places.
MacOS is like driving a car by yelling at the driver from the kids seat in the back.
In the end, learning how an engine works to maintain one myself is not so bad.
There's also a timing issue. Often when something goes wrong it's at a random time when I'm probably intending to do something else. I don't want to put off that other thing even more by taking a "slower" route to fixing the issue.
You can of course still learn a lot along the way, as you say. So, it's not all lost, but it does seem sub-optimal.
On the other hand, if the solution to a problem on Linux is to change some dotfile controlling some daemon, reliably scripting it can be difficult to impossible. Did the distro put the config file somewhere weird? Is awk good enough here? What if the key I'm looking to update is found in a comment, and what is the commenting structure for this file anyway? What if the daemon rewrites its config file on exit [0]? Or has a config file with an extremely complex format [1]? Or I need to poke several /sys files in a particular order [2]?
Both systems are hard to reason about, especially if you don't know them. But Linux isn't easy to approach for the first time, and there are advantages to the way Windows does things.
[0]: https://askubuntu.com/questions/251797/transmission-daemon-k... [1]: https://www.sudo.ws/docs/man/1.8.15/sudoers.man/#SUDOERS_FIL... [2]: https://www.youtube.com/watch?v=9-IWMbJXoLM
- for windows, the problem is solved by:
- for linux, you also get:I recently had an OpenGL related issue on Linux, I googled the error message and got 1 search result. Now I can speculate, is my program wrong? Or is it the Nvidia driver, perhaps Xorg? Did the Ubuntu devs configure something wrong etc.
Why won't Nsight or Renderman work on my machine?
Windows has by contrast a significantly larger userbase, an architecture that's set in stone, meaning I can find relevant answers from a decade ago, and there's thankfully no Windows 'distributions' so the issue I face is likely to appear on any person's machine.
I always felt I could dive deeper with linux problems _if I wanted to_, and that weirdly gives me some confidence that I can fix it.
Same, in fact it's how I fell ass-backwards into my career path.
> I spent several hours fixing a problem and I learned next to nothing in the process. This trick is unlikely to be useful again. By the time I encounter something similar, it is likely I will have forgotten about the solution.
So much this.
Perhaps dkozel is reading this right now. :P
https://news.ycombinator.com/threads?id=dkozel
https://lobste.rs/threads/dkozel
I really want to move to Linux but unless my laptop manufacturer provides support, its never going to happen. I don't want to think my OS when buying a hardware accessary or a software product.
A laptop's a tool and Windows still provides the most support.
2 - Have you actually tried Linux?
My KDE Plasma setup is nothing like MacOS.
Personally, I've been riding the linux struggle bus for years in my personal time. It really hasn't been a struggle, but weird issue's I've dealt with during my "Linux evenings" has made obscure struggles at my day job far easier to debug and deal with, and overall has made me a better engineer because I know how my tools work and I can use them more effectively.
It's a whole lot more fun learning about kernel drivers, systemd, networking drivers, etc when you're personally invested in tweaking your machine just right. I much rather deal with a Linux issue for an hour than spend an hour on leetcode.
Anything you use has a chance of failure and on the whole I feel Linux has taken less time to do what I want to do with it than other similar options.
Thought I started using macOS at home because I got tired of dealing with Linux desktop shit, so take that as you will.
> “If you’ve ever read a mystery story you know that a detective never works so hard as when he’s on vacation. He’s like the postman who goes for a long walk on his day off.”
I got tired of taking the long walks.
If you're dealing with new hardware, situations like the one described in the article may pop up since vendors will focus their testing on Windows (and possibly macOS) so there is a good chance that it will work on the commercial operating systems but not the open source ones. That is going to be especially true to more exotic hardware since there will also be less testing by the open source community.
On the other hand, I find managing a Linux system significantly more time efficient. Some of it is because of the nature of open source. For example: installing, updating, and removing software is much easier since the licensing model allows distribution maintainers to create a universal software management tool. In other cases, it is simply because of the approaches typically taken by open source developers. For example: it is usually easy to copy configuration files from one system to another.
To me, a lot of the frustrations boiled down to familiarity. I used to be touchy around Linux, because it was weird to me all the time, switching from a decade plus of Windows experience. Whatever broke with Linux, it was a Linux problem, and whatever broke in Windows, it was a stupid computer problem. Do you see the bias? Now that I have the user experience, Linux issues are familiar, and whenever there's anything that's out of place, I know where to look, what to search. And Windows, with its penchant to reorganize the Control Panel every release, seems like a maze to me, where I get more frustrated at every turn.
At the end of the day, it's pick your poison really.
Yes and no. I think if our only tools are are Google (well, now Kagi for me), Stack overflow et al., and the sites that hold quality content quick to the point, you'll be spending a lot of time on the info finding and not the fixing.
I think it requires a a lot of information organization tools to continue to keep up with it. Or sink more time into info finding. Or just memorize everything if you have a brain for that