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

101–110 of 330 posts

Re: A Linux Evening

#101

Post by danobi »

noisy_boy wrote: post #84
torben-friis wrote: post #76

Earlier quoted context omitted.

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…

I use stock ios and mobius sync works pretty well. No issues so far over 1y+ of use.

Re: A Linux Evening

#102

Post by [deleted] »

deltarholamda wrote: post #80
revolvingocelot wrote: post #56

Earlier quoted context omitted.

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

>I'm not sure what I learned. "Have you tried turning it off and on again?"

[deleted]

Re: A Linux Evening

#103

Post by nebulous1 »

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

Re: A Linux Evening

#104

Post by swayvil »

antihero wrote: post #91
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…

Linux is like driving a car with your hands in the engine

This contradicts my experience.

I use Linux every day and I never touch the engine.

I also set up Linux for computer-illiterate old ladies. They love it.

Re: A Linux Evening

#105

Post by diydsp »

>This trick is unlikely to be useful again.

Ahh, but now others can benefit from your work :) It's a system or a community. The wizards hand off to the communicators and enable more users.

>In the meantime, the best I can think of is to pay for my distro, report bugs, and email manufacturers for Linux support.

Hell yeah! and keep posting technical solutions. Even the little things you do like keeping your site very readable, posting the text instead of screenshots so it's searchable, etc. all help.

>dkozel and your kind, whoever you are, wherever you are, and whatever you are doing right now, you are legend.

You too, man. Remember Gandi's quote: “Whatever you do will be insignificant, but it is very important that you do it.”

Re: A Linux Evening

#106

Post by vq »

eythian wrote: post #57
postit wrote: post #32

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.

You recall correctly.

https://www.dell.com/community/XPS/FAQ-Modern-Standby/td-p/7...

Re: A Linux Evening

#107

Post by kalleboo »

alkonaut wrote: post #49
jeromenerf wrote: post #19

Kernel parameters are usually documented in the kernel-parameters.txt file in the source. See https://github.com/torvalds/linux/blob/master/Documentation/... : hpbussize=nn The minimum amount of additional bus numbers reserved for buses below a hotplug bridge. Default is 1. The way to get from the error "No bus number available for hot-added bridge" at https://github.com/torvalds/linux/blob/master/drivers/pci/pr... t…

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?

According to another comment (https://news.ycombinator.com/item?id=34013844), macOS will pause, reallocate, and un-pause the bus.

Re: A Linux Evening

#108

Post by varispeed »

I don't see the drive connection type is as important as making sure your backup data stays encrypted.

Now doing this across different operating systems is clunky and quite challenging.

You could use something like True Crypt or Vera Crypt, but mounting your drive then won't be typically as simple as plugging it in.

For that reason it's probably better to have a separate computer for backups connected to the network. That way you don't need to care about encryption on every system you connect it to. It just works (tm).

Re: A Linux Evening

#109

Post by kalleboo »

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.

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

Re: A Linux Evening

#110

Post by asoneth »

gbin wrote: post #29

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.

Post reply on HN