Re: off topic: feedback after 3 months with Linux

[Richard Heck]

On 10/31/2017 08:21 PM, Uwe Stöhr wrote:
> El 31.10.2017 a las 03:05, Richard Heck escribió:
>
>>> I realized that Linux's monolithic kernel is a problem. Every device
>>> driver needs to be part of the kernel.
>>
>> This is a confusion. Linux supports kernel modules, which are the exact
>> Linux equivalent of a device driver, and which can be installed
>> separately from the kernel itself.
>
> OK, but the WLAN driver is part of the kernel, not of a kernel module.
> This bug cost me many hours to investigate until I learned that I need
> to recompile the kernel with the fixed driver. I can also not e.g. use
> another version of the Mesa driver - it has to be compiled with the
> kernel too. So why are the drivers no modules? 

This is a question you could ask of the people at your distro. They made
a decision to compile the kernel so that iwlwifi was integrated into it
and not a module. This page from gentoo
 https://wiki.gentoo.org/wiki/Iwlwifi
specifically explains how one can configure the kernel to make iwlwifi a
module, if one wants to do that, so I'm not making it up. One can do
this with almost any device driver. Granted, you may not want to
reconfigure the kernel yourself. My point was just that it has nothing
to do with Linux. It's a choice your distro made when they configured
your kernel.

The distro could perfectly well decide to configure the kernel so that
iwlwifi was a module. Then they could offer updates to it without having
to update the whole kernel. That's up to them.

>>> Someone in a forum explained me that the kernel needs to be
>>> compiled using the fixed driver before it will work. But compiling the
>>> kernel as a normal user? No chance.
>>
>> In the Windows world, you do not even have this option. You have to wait
>> until Microsoft or the manufacturer decides to issue a patch.
>
> No, there I can always go back to a previous driver version that is
> known to work. For my WLAN problem I found out that there were older
> driver versions without the bug but I could not use them.

Why can't you use an older kernel? Just install it. You can even install
it alongside the newer one you already have. I have done that many
times. If your distro doesn't offer older kernels, then that is a
problem you have with them, again.

>> Wait until they issue a patch. I'll bet that Linux distros are faster
>> to do that
>> than Windows is.
>
> That is my point. Waiting is a no go in real life. Every hour a person
> is not productive produces costs. That is why companies have 24h
> support contracts. I mean if you cannot e.g. transfer parts from your
> CAD to the CAM software of the machine, the machine is not running.
> This costs a lot of money every hour.

And my point is that bugs are a fact of life, and if you have a bug you
will get it fixed a whole lot faster by the Linux community than you
will by some commercial monopoly. If you want to pay for support, then
you can have someone compile the new kernel for you. You can even pay
people to fix bugs for you. Much as with LyX. You do not have any of
these options with closed-source drivers.

And of course you can compile the new kernel yourself. I compiled my own
kernel very shortly after I became a Linux user, for a reason not unlike
yours. Compiling things on Linux is so, so much easier than on other
platforms, and compiling the kernel is no more difficult than compiling
LyX. It's actually very easy, especially if you just want to use the
same configuration (what drivers are included, etc) as your default
kernel, which in your case would be fine. You just need to fix a bug,
not activate a driver your distro didn't include (which is what I needed
to do, since I had a weird wifi card).

Here's how to do it. Get the source for the kernel you are currently
using. Apply the patch you need to fix the bug that's affecting you. (Or
get the source for a new kernel.) What follows then happens from within
the source directory.
    # copy the existing configuration
    cp /boot/config-`uname -r`* .config
    # create the new configuration
    make defconfig
    # build the kernel
    # this will take a while!
    make
    # install the new kernel
    sudo make modules_install
    sudo make install
    # update the bootloader
    sudo update-grub2
Now reboot and choose your new kernel as the one you want to run.

See this page
    https://kernelnewbies.org/KernelBuild
for more info. Note the remarks at the end about how, if the only change
was to a module, you only need to recompile that part of the tree.

That was all for Ubuntu. You may have to make some minor changes, but
they won't affect how easy it is. You may also have to install some
packages in order to compile the kernel. Obviously, e.g., you need a
compiler!

> There must be a reason why no production company I know uses Linux for
> other things than server applications. 

Many massively parallel machines run Linux:
   

Re: off topic: feedback after 3 months with Linux

[Uwe Stöhr]

El 31.10.2017 a las 03:05, Richard Heck escribió:


I realized that Linux's monolithic kernel is a problem. Every device
driver needs to be part of the kernel.


This is a confusion. Linux supports kernel modules, which are the exact
Linux equivalent of a device driver, and which can be installed
separately from the kernel itself.


OK, but the WLAN driver is part of the kernel, not of a kernel module. 
This bug cost me many hours to investigate until I learned that I need 
to recompile the kernel with the fixed driver.
I can also not e.g. use another version of the Mesa driver - it has to 
be compiled with the kernel too. So why are the drivers no modules?


I am a newbie and don't know the internals. I only noticed that the 
driver/kernel thing is for me a problem.



Someone in a forum explained me that the kernel needs to be
compiled using the fixed driver before it will work. But compiling the
kernel as a normal user? No chance.


In the Windows world, you do not even have this option. You have to wait
until Microsoft or the manufacturer decides to issue a patch.


No, there I can always go back to a previous driver version that is 
known to work. For my WLAN problem I found out that there were older 
driver versions without the bug but I could not use them.



Wait until they issue a patch. I'll bet that Linux distros are faster to do that
than Windows is.


That is my point. Waiting is a no go in real life. Every hour a person 
is not productive produces costs. That is why companies have 24h support 
contracts. I mean if you cannot e.g. transfer parts from your CAD to the 
CAM software of the machine, the machine is not running. This costs a 
lot of money every hour.
There must be a reason why no production company I know uses Linux for 
other things than server applications. Maybe the driver architecture is 
one reason. I don't know.


I don't want to judge that one system is better or not. I am just 
looking around for an alternative that allows me to be as productive as 
with Windows. As I wrote I will keep Linux as second system.


regards Uwe

Re: off topic: feedback after 3 months with Linux

[Uwe Stöhr]

On 31.10.2017 14:24, Paul A. Rubin wrote:

That's curious. I didn't have any problems with Xreader and gender radio 
buttons in PDF-form.lyx.


- open the PDF of PDF-form.lyx with the latest Xreader 1.4.4.
- then go to sec. 2.3 and you can see that you cannot select "female".
- go to sec. 2.1 to see that the second text filed is not filled with 
the content of the first one as it should be
- go to sec. 4 to see that the buttons to save the form and for 
fullscreen view are not orking

- go to sec. 2.4 and yo see that no button there works

>
 In any case, I would definitely recommend

getting the Linux version of Acrobat Reader.


This version is no longer under development since years and therefore a 
security risk to use it.


regards Uwe

Re: configure.py regression in RC1 compared to beta

[Scott Kostyshak]

On Tue, Oct 31, 2017 at 09:19:49AM +, Stephan Witt wrote:
> Am 30.10.2017 um 08:31 schrieb Scott Kostyshak :
> > 
> > On Sun, Oct 29, 2017 at 09:10:23PM +, Uwe Stöhr wrote:
> >> El 29.10.2017 a las 16:52, Jürgen Spitzmüller escribió:
> >> 
> >>> Note that I am traveling. So if it works on the Mac, someone will have
> >>> to cherry-pick it.
> >> 
> >> I might also not be able to commit soon. So Scott, could you please do this
> >> if Stephan gave his OK?
> > 
> > Yes I can take care of that once Stephan has a chance to test.
> 
> I did the test with a checkout of 2.3.x and the cherry-picked change
> 22125fa6de76ec884a0a0c41506e78a8fdae575c and I tested it with and w/o
> inkscape and it works for me on Mac. Thank you, Jürgen.

Thanks for testing, Stephan. I'm glad we got this figured out.

I've cherry-picked and pushed the commits. I'll send the new tars in a
bit.

Scott

> Stephan
>
> > Thanks a lot, Jürgen and Uwe for figuring out a fix.


signature.asc
Description: PGP signature

Re: off topic: feedback after 3 months with Linux

[Paul A. Rubin]

On 10/30/2017 07:29 PM, Uwe Stöhr wrote:


I tried the PDF-form.lyx experiment. The default PDF viewer on my 
system (Xreader) seemed to handle most of the form features.


I also tried Xreader. There are several bugs in all PDF programs under 
Linux. For me the main bug is that I cannot use radio buttons but 
these are in most PDF forms (e.g. for sex/gender). Of course I already 
reported all bugs I found.
That's curious. I didn't have any problems with Xreader and gender radio 
buttons in PDF-form.lyx. In any case, I would definitely recommend 
getting the Linux version of Acrobat Reader. You can easily make it the 
default program for opening PDFs. I've never had any problems with it on 
Linux, and radio buttons work.


Paul

Re: Initial view of document (master)

[Jean-Marc Lasgouttes]

Le 31 octobre 2017 11:52:57 GMT+01:00, Pavel Sanda  a écrit :
>Jean-Marc Lasgouttes wrote:
>> Yes, this is needed in some cases. I see 3 types of fixes
>> 1. Convince qt that there is no need to update a whole window when
>the status bar changes
>> 2. Audit the uses of Buffer::message and use something else when
>possible.
>> 3. Change row painting code so that it does not have to use the
>actual paragraph contents. This was already on my to-do list for other
>reasons.
>
>I would probably end up with 2, but I am not really competent to give
>advices about the painting code...


Yes 2 is good for fixing the symptom, but it is very fragile...

JMarc

Re: Initial view of document (master)

[Pavel Sanda]

Jean-Marc Lasgouttes wrote:
> Yes, this is needed in some cases. I see 3 types of fixed
> 1. Convince qt that there is no need to update a whole window when the status 
> bar changes
> 2. Audit the uses of Buffer::message and use something else when possible.
> 3. Change row painting code so that it does not have to use the actual 
> paragraph contents. This was already on my to-do list for other reasons.

I would probably end up with 2, but I am not really competent to give advices 
about the painting code...

Pavel

Re: configure.py regression in RC1 compared to beta

[Stephan Witt]

Am 30.10.2017 um 08:31 schrieb Scott Kostyshak :
> 
> On Sun, Oct 29, 2017 at 09:10:23PM +, Uwe Stöhr wrote:
>> El 29.10.2017 a las 16:52, Jürgen Spitzmüller escribió:
>> 
>>> Note that I am traveling. So if it works on the Mac, someone will have
>>> to cherry-pick it.
>> 
>> I might also not be able to commit soon. So Scott, could you please do this
>> if Stephan gave his OK?
> 
> Yes I can take care of that once Stephan has a chance to test.

I did the test with a checkout of 2.3.x and the cherry-picked change
22125fa6de76ec884a0a0c41506e78a8fdae575c and I tested it with and w/o
inkscape and it works for me on Mac. Thank you, Jürgen.

Stephan

> Thanks a lot, Jürgen and Uwe for figuring out a fix.
> 
>> Moreover, I propose to commit configure.py as it is in master to 2.3 because
>> it also had some improvements LyX 2.3 should benefit from.
> 
> I'll cherry-pick Jürgen's change regarding WMF -> EPS converter. I don't
> want the commit that stores text editors in a variable in RC1 (even
> though I requested that improvement) since it is more of a long-run
> benefit fix. If there's another commit regarding configure.py that you
> think should be backported, let me know. We have to be careful because
> we want compatibility between different Python versions, and even small
> changes that appear harmless can break compatibility that we might not
> catch.
> 
> Scott