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)
Problem #1: there are 2. One ending in G05 and one ending in G04. I can't find anything official or canonical with Google as to which package installs which GPUs. At least nVidia's website tells you that for its drivers -- but not for *SUSE's.
can't you just install both and the one matching the PCI ID of your card will be used? (Just guessing, I'm not going to touch NVidia with a 10 foot pole if not getting paid for it)
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.
Second reason: because we have blasted systemd now and as a result of that, half the most common basic logfiles have bally well disappeared and are now in some binary log format I don't know, hidden I don't know where and only viewable by a tool I don't know.
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". (and if you read up on the factory archives, probably nobody will think I'm a systemd apologist, but criticizing it just "because it's systemd" is certainly not making you look smart)
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.
I still have the same email address as I did in 1991 and I have a system for generating unique passwords in my head, so I can work out what password I used, even 25 years later.
But I am very unusual.
Yes, but rather for being unable to find "journalctl" or "zypper in rsyslog" with a very quick google search ;-)
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 ;-)
Other examples: you want to test a connection to another machine by IP address. What commands might you use?
Again: 2nd/3rd line support. I was some 46 years old at the time.
This is _not_ basic stuff any more.
Of course it is. Maybe not at IBM.
Stuff like this highlights problems that may be niche when the offending driver is $FOO but then 6 months later you find it also affects driver $BAR and some company is shipping a million devices a day that need driver $BAR.
Heartbleed.
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. And exactly because fringe code has such stupid bugs, we disable the drive-by-autoloading of random file systems.
This stuff really happens.
Don't leave edge cases because they're obscure or niche because it's a law of nature they'll come back and bite you.
Totalla agreed, don't leave the attack surface open. Blacklist fringe filesystems NOW! :-) -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org