Because Shiny Things Are Fun - The New New Windows v Linux Thread

Originally Posted by Germany_chris There is no jumper nor will removing the cmos battery, nor tpm setup. Been there done that got the t-shirt, ice cream cone, and cookie.

Than you have a unique motherboard, in all the years working in IT I never have seen a mainboard without that jumper, unless it is a laptop. In that case removing the CMOS battery and short circuiting the contacts on the mainboard worked (though for some laptops it is a whole bunch of work to actually have access to the battery).

Originally Posted by TobiSGD Than you have a unique motherboard, in all the years working in IT I never have seen a mainboard without that jumper, unless it is a laptop. In that case removing the CMOS battery and short circuiting the contacts on the mainboard worked (though for some laptops it is a whole bunch of work to actually have access to the battery).

Yes, a laptop.

When we got these in at work the passwords we told folks to set the password after the 4th motherboard was replaced by Dell for the forgotten password they stopped the policy. If it was as simple as a BIOS password pulling the battery, the CMOS battery, and holding the power for 10 seconds would clear it generally.

I finally found something I don't like about Linux: making and installing drivers.

This whole process is bizarre. Finally was able to make a simple 'hello.ko' driver install, after a week of fiddling (which included having to recompile the kernel). This is not good.

Having said that, a while back, I was able to make a video driver to fix an issue I was having with videos not resizing. The instructions I followed didn't include recompiling the kernel, and the driver works fine. So there is a mystery there somewhere.

Originally Posted by linux_walt I finally found something I don't like about Linux: making and installing drivers. This whole process is bizarre. Finally was able to make a simple 'hello.ko' driver install, after a week of fiddling (which included having to recompile the kernel). This is not good. Having said that, a while back, I was able to make a video driver to fix an issue I was having with videos not resizing. The instructions I followed didn't include recompiling the kernel, and the driver works fine. So there is a mystery there somewhere.

This is something I disagree with but YMMV

Making drivers isn't exactly easy for any other large OS

Things are getting better, but the real problem with drivers is that they are written pre-certified for MS and/or OSX compatibility. Until peripheral manufacturers open their code, Linux will always be at least a step behind proprietary land in providing solutions for the latest hardware offerings.

Originally Posted by enine Making drivers isn't exactly easy for any other large OS

This

Originally Posted by TobiSGD The same attack vector is possible against Linux systems. Once an attacker has physical access to a machine you are pretty much lost. Anyone that can boot an OS from USB at your computer can do whatever he wants on the installed OS, regardless if Linux or Windows, unless you use enhanced security features like full disk encryption.

Seriously, though, if your computer hardware is in such an insecure state as to be accessible by any joe blow with a USB stick or CD, I would think that the least of your problems is the compromising of your OS. If the computer is that physically accessible, you'd be lucky that the machine still remained at all.

Originally Posted by enine Making drivers isn't exactly easy for any other large OS

Apologies I was trying to be brief and didn't state my argument well. The problem, from my newcomer perspective, is not that the procedure for making a driver is difficult. It's that there does not seem to be a standard interface to the kernel: the driver has to be built to run on your, possibly very particular, version of the kernel. There could also be problems if a different compiler is used for the driver, than was used for the kernel (cannot find reference for this at the moment).

I understand that it may be difficult to have a standard interface to the kernel, since it's constantly being updated. However, couldn't some kind of usb-like enumeration scheme be implemented? For example, when the driver indicates what kernel functions it will be using, the kernel could pass on the corresponding function prototypes to the driver, instead of the driver having a hard coded prototypes of the kernel functions, which could be the wrong ones for this kernel.

Likewise the driver could pass to the kernel it's function prototypes that it would like to make public.

Now I can see some problems, even with my limited programming experience. It would be a bit of a nightmare trying to write a module that recoded itself, based on function prototypes passed to it by the kernel. However there is something called function overloading that maybe could be used by the driver code?

Another possibility might be to have information between kernel and module passed in pseudocode:

The purpose of using pseudocode is that it is easier for people to understand than conventional programming language code, and that it is an efficient and environment-independent description of the key principles of an algorithm

Left out this part of the quote since it detracts from my argument :

Pseudocode typically omits details that are essential for machine understanding of the algorithm...

Anyways, there could be a kernel module just for translating 'pseudocode' received from a driver, into a format compatible with that particular kernel. Likewise for the driver, for pseudocode received from the kernel. It should only be necessary to do this once.

Of course this translator could not become another moving target, with constant changes and patches, without backwards compatibility.

Pie in the sky, or maybe a thought in the right direction?

I'm tempted to give windows a hands down win on this one, but after some thought, an analogy comes to mind. You can have a microsoft house, and buy windows and doors anywhere, because they are all the same size. Or you could build your own house, with the windows and doors any size you like, but then you have to build your own windows and doors. I guess it depends on you, how important one is over the other, and how much time you have available.

Part of my gripe then seems unfair: I bring home a star shaped window, and expect the wall to change shape on it's own. But maybe this is just a waiting opportunity for someone to invent a flexible window frame that doesn't look ugly.

Originally Posted by curtvaughan Things are getting better, but the real problem with drivers is that they are written pre-certified for MS and/or OSX compatibility. Until peripheral manufacturers open their code, Linux will always be at least a step behind proprietary land in providing solutions for the latest hardware offerings.

I know it doesn't sound right in a Linux context, but why should the OEM be required to open their code. This part I have trouble with. Maybe a system could be set up whereby, if you trust the OEM, you connect to their website and send all the info required to make a driver for your setup. An automated system on the other end would make the driver, then download and install. This way everyone should be happy.

Originally Posted by linux_walt I know it doesn't sound right in a Linux context, but why should the OEM be required to open their code. This part I have trouble with. Maybe a system could be set up whereby, if you trust the OEM, you connect to their website and send all the info required to make a driver for your setup. An automated system on the other end would make the driver, then download and install. This way everyone should be happy.

I believe this is the strategy nvidia uses.
It doesn't work as well as it might sound

If you make hardware then you should make it easily accessible to use that hardware.
Locking down drivers into binary blobs that don't work and the company doesn't try to make it work does not meet my definition of "easily accessible".

https://4.bp.blogspot.com/_lsk9jdryG...chSupSMALL.jpg

That is how I fix my driver installs.

Easy Peasy.

There must be a reason why someone decides not to make the driver source code available. All I can think of is that it may help reverse engineer hardware that they have spent a lot of money developing.

Originally Posted by linux_walt There must be a reason why someone decides not to make the driver source code available. All I can think of is that it may help reverse engineer hardware that they have spent a lot of money developing.

NVidia has never been customer friendly. They have always been about the $$$

Originally Posted by linux_walt There must be a reason why someone decides not to make the driver source code available. All I can think of is that it may help reverse engineer hardware that they have spent a lot of money developing.

That, and NDA's, where they are licensing others tech. I think I have read that is part of why Nvidia's code is binary only, and I remember that Bios had to be reverse engineered.
That said, Miati has it a bit wrong, as Nvidia, doesn't create a driver based on your hardware/software spec's the way linux_walt's post read to me. They just provide precomplied ones.
When there is hardware available with an open bios, as well as an open os, I think development could gain a boost, enough to make other companies consider trying it. Unfortunately, I see it as a catch 22.