Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A Linux Evening

fabiensanglard.net

Post reply on HN
Print view View original

241–250 of 330 posts

Re: A Linux Evening

#241

Post by pessimizer »

vehemenz wrote: post #116

1. If you don't encounter any trouble daily driving GNU/Linux, that is actually a sign of inexperience . That or you're doing nothing interesting. 2. If principles mattered more than convenience, most Linux users would be on FreeBSD or OpenBSD instead of GNU/Linux. Either follow your arguments to their conclusions, or understand that Windows/macOS users are doing the same thing as you—making practical tradeoffs. 3. U…

> If principles mattered more than convenience, most Linux users would be on FreeBSD or OpenBSD instead of GNU/Linux. Either follow your arguments to their conclusions, or understand that Windows/macOS users are doing the same thing as you—making practical tradeoffs.

I'm chiming in with everybody else here, but why do you think that my principles are better served by licensing that is less supportive of my principles?

Re: A Linux Evening

#243

Post by HideousKojima »

markus_zhang wrote: post #229
bombcar wrote: post #149

Earlier quoted context omitted.

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.

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 progr…

>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.

Re: A Linux Evening

#244

Post by bee_rider »

AnIdiotOnTheNet wrote: post #61
nneonneo wrote: post #54

Earlier quoted context omitted.

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 de…

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?

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.

Re: A Linux Evening

#245

Post by forrestthewoods »

quijoteuniv wrote: post #9

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.

> 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.

Re: A Linux Evening

#246

Post by pessimizer »

emsy wrote: post #7
tuukkah wrote: post #5

Earlier quoted context omitted.

How is your comment related to the article? The only connection I can see is bad quality of some hardware and drivers.

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.

> 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.

Re: A Linux Evening

#247

Post by aiwv »

jeffbee wrote: post #72
alkonaut wrote: post #49

Earlier quoted context omitted.

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.

Raises the question whether or not anyone writing this kind of software actually uses it.

Re: A Linux Evening

#248

Post by jodrellblank »

arghwhat wrote: post #235
jodrellblank wrote: post #191

Earlier quoted context omitted.

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".

> 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 t…

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.

[1] https://news.ycombinator.com/item?id=34016094

Re: A Linux Evening

#250

Post by m463 »

nebulous1 wrote: post #103
nicoco wrote: post #33

> 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…

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 s…

I think the two problem spaces are slightly different.

- for windows, the problem is solved by:

  1) common sense troubleshooting
  2) web search for the problem
  3) ask the developer
- for linux, you also get:

  4) break out the source
  5) push an update
Post reply on HN