On 2/6/19 8:38 AM, Liam Proven wrote:
On 2/5/19 6:57 PM, Stefan Seyfried wrote:
Am 05.02.19 um 18:32 schrieb Liam Proven:
Because, for the most part, people _are_ stupid.
You should not extrapolate from yourself! ;-)
(SCNR, of course this is not meant seriously)
:-D
No problems at all.
can't you just install both and the one matching the PCI ID of your card will be used?
I confess I have not tried, but previous experience with previous nVidia drivers on other distros suggests that no, this won't work. The driver only supports one instance at a time.
(Just guessing, I'm not going to touch NVidia with a 10 foot pole if not getting paid for it)
*Shrug* It's the machine SUSE gave me.
Because that's not how it works on Windows and that's all most PC users know.
Of course that's how I debug windows failures, too. Look at the event log viewer. The tools are just inferior.
Agreed.
But most Windows users _don't_ debug failures. At all. They might pay someone else to.
Well, digging through a zillion of log files in /var/log is certainly easier than "journalctl -b", which shows you all relevant logs from this boot (not the old, irrelevant ones) and even marks them with colors according to the severity level.
I don't think I'd subscribe to your view of "easy".
I use the traditional Unix methods that I know and have used for ~3 decades. I do not run servers for a living, or develop software, or build distros. If the methods have changed and don't work, my first response, generally, is not "excellent, let's learn something new!" My first response is more like to be "can I put the old method back?"
I am not arguing that this is the best attitude, but I bet it's a fairly common one.
So when I started troubleshooting TW, a very early step was to install some package that disables systemd's binary logging and gives me actual logfiles again. *Then* I had to wait for various problems to occur again so that now I could actually look into plain text logfiles with ``less'' and find out what was going on.
This took extensive googling. [...]
But I am very unusual.
Yes, but rather for being unable to find "journalctl" or "zypper in rsyslog" with a very quick google search ;-)
Hang on. In _the previous paragraph_ I said that this is exactly what I did.
Come on, be fair.
True story. 4y ago I interviewed with IBM for a midrange tech support job, 2nd/3rd level.
The first interview question was: on a Windows machine, where would you look for error logs?
This is a question they use to weed out _advanced_ techies from normal techies.
If you ever have talked to an IBM "advanced techie" then you know that the only thing advanced about this is the price tag. I wonder if anyone but IBM can pull such a thing ;-)
*LOL*
That may be so.
My point is, it's not _basic_ troubleshooting knowledge. Yes, it probably should be, but it isn't.
Heartbleed was not exactly a "niche case". Anecdote: when colleagues had heard rumers about the new "heartbleed-WE_AR_ALL_GOING_TO_DIE!!!1!!!"-Bug, my first thought was "I don't believe it, it can't be that bad. Rogue memory read, ok, but how high is the probability that attackers will read interesting things?". Until the bug was published, I looked at the code, saw that these morons had implemented their own, inferior memory management and thus ensured that the interesting data (keys,...) was exactly at the same place everytime and easily accessible. Something that would not have happened with a modern system malloc() or such.
There are different ways to address this.
One, which in my personal non-day-job life I quite favour, is to be interested in OSes which contain no C code at all and look forward to the days when the entire C and Unix family is ancient history.
Another extreme is to trust nothing and be very paranoid. But then, OpenBSD is, and it still happened.
It is simply that turning stuff off instead of fixing it seems short-sighted to me.
It's a simple cost-benefit analysis. Developer time (even if it's volunteer) isn't free. If you want to invest your personal time in auditing and improving every file system that Linux supports, that's certainly your prerogative. As those file systems are improved, we can discuss removing them from the blacklist. -Jeff -- Jeff Mahoney SUSE Labs