Mailinglist Archive: opensuse-factory (602 mails)

< Previous Next >
Re: [opensuse-factory] Re: [PLEASE SPEAK UP] Disabling legacy file systems by default?
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)


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

Of course that's how I debug windows failures, too. Look at the event
log viewer. The tools are just inferior.


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

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

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


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.

Totalla agreed, don't leave the attack surface open. Blacklist fringe
filesystems NOW!



Liam Proven - Technical Writer, SUSE Linux s.r.o.
Corso II, Křižíkova 148/34, 186-00 Praha 8 - Karlín, Czechia
Email: lproven@xxxxxxxx - Office telephone: +420 284 241 084

To unsubscribe, e-mail: opensuse-factory+unsubscribe@xxxxxxxxxxxx
To contact the owner, e-mail: opensuse-factory+owner@xxxxxxxxxxxx

< Previous Next >
List Navigation
This Thread
Follow Ups