LinuxQuestions.org
Visit Jeremy's Blog.
Go Back   LinuxQuestions.org > Forums > Non-*NIX Forums > General
User Name
Password
General This forum is for non-technical general discussion which can include both Linux and non-Linux topics. Have fun!

Notices


Reply
  Search this Thread
Old 01-31-2015, 12:23 PM   #2221
TobiSGD
Moderator
 
Registered: Dec 2009
Location: Germany
Distribution: Whatever fits the task best
Posts: 17,148
Blog Entries: 2

Rep: Reputation: 4864Reputation: 4864Reputation: 4864Reputation: 4864Reputation: 4864Reputation: 4864Reputation: 4864Reputation: 4864Reputation: 4864Reputation: 4864Reputation: 4864

Quote:
Originally Posted by Germany_chris View Post
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).
 
Old 02-01-2015, 02:49 AM   #2222
Germany_chris
Senior Member
 
Registered: Jun 2011
Location: Watertown, NY
Distribution: Arch
Posts: 1,049

Rep: Reputation: 492Reputation: 492Reputation: 492Reputation: 492Reputation: 492
Quote:
Originally Posted by TobiSGD View Post
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.
 
Old 02-22-2015, 04:48 PM   #2223
linux_walt
Member
 
Registered: Dec 2014
Location: Houston, TX
Distribution: Debian wheezy
Posts: 127

Rep: Reputation: 29
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.

Last edited by linux_walt; 02-22-2015 at 04:53 PM.
 
Old 02-23-2015, 12:01 PM   #2224
Germany_chris
Senior Member
 
Registered: Jun 2011
Location: Watertown, NY
Distribution: Arch
Posts: 1,049

Rep: Reputation: 492Reputation: 492Reputation: 492Reputation: 492Reputation: 492
Quote:
Originally Posted by linux_walt View Post
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
 
Old 02-23-2015, 01:00 PM   #2225
enine
Senior Member
 
Registered: Nov 2003
Distribution: Slackware 14.2, SlackwareArm-current
Posts: 1,217
Blog Entries: 4

Rep: Reputation: 183Reputation: 183
Making drivers isn't exactly easy for any other large OS
 
Old 02-23-2015, 01:05 PM   #2226
curtvaughan
Member
 
Registered: Nov 2014
Location: Austin, TX
Distribution: Mint, Devuan, MX, Ubuntu, ArcoLinux on hardware; vboxes of varying flavors
Posts: 42

Rep: Reputation: Disabled
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.
 
Old 02-23-2015, 01:18 PM   #2227
smeezekitty
Senior Member
 
Registered: Sep 2009
Location: Washington U.S.
Distribution: M$ Windows / Debian / Ubuntu / DSL / many others
Posts: 2,339

Rep: Reputation: 231Reputation: 231Reputation: 231
Quote:
Originally Posted by enine View Post
Making drivers isn't exactly easy for any other large OS
This
 
Old 02-23-2015, 01:19 PM   #2228
curtvaughan
Member
 
Registered: Nov 2014
Location: Austin, TX
Distribution: Mint, Devuan, MX, Ubuntu, ArcoLinux on hardware; vboxes of varying flavors
Posts: 42

Rep: Reputation: Disabled
physical computer security

Quote:
Originally Posted by TobiSGD View Post
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.
 
Old 02-23-2015, 03:28 PM   #2229
linux_walt
Member
 
Registered: Dec 2014
Location: Houston, TX
Distribution: Debian wheezy
Posts: 127

Rep: Reputation: 29
Quote:
Originally Posted by enine View Post
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:
Quote:
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 :
Quote:
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.

Last edited by linux_walt; 02-23-2015 at 05:11 PM.
 
Old 02-24-2015, 08:36 AM   #2230
linux_walt
Member
 
Registered: Dec 2014
Location: Houston, TX
Distribution: Debian wheezy
Posts: 127

Rep: Reputation: 29
Quote:
Originally Posted by curtvaughan View Post
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.

Last edited by linux_walt; 02-24-2015 at 08:38 AM.
 
Old 02-24-2015, 09:47 AM   #2231
Miati
Member
 
Registered: Dec 2014
Distribution: Linux Mint 17.*
Posts: 326

Rep: Reputation: 106Reputation: 106
Quote:
Originally Posted by linux_walt View Post
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".
 
Old 02-24-2015, 11:04 AM   #2232
rokytnji
LQ Veteran
 
Registered: Mar 2008
Location: Waaaaay out West Texas
Distribution: AntiX 17
Posts: 5,840
Blog Entries: 21

Rep: Reputation: 2921Reputation: 2921Reputation: 2921Reputation: 2921Reputation: 2921Reputation: 2921Reputation: 2921Reputation: 2921Reputation: 2921Reputation: 2921Reputation: 2921
https://4.bp.blogspot.com/_lsk9jdryG...chSupSMALL.jpg

That is how I fix my driver installs.

Easy Peasy.
 
Old 02-24-2015, 11:49 AM   #2233
linux_walt
Member
 
Registered: Dec 2014
Location: Houston, TX
Distribution: Debian wheezy
Posts: 127

Rep: Reputation: 29
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.

Last edited by linux_walt; 02-24-2015 at 12:59 PM.
 
Old 02-24-2015, 01:02 PM   #2234
smeezekitty
Senior Member
 
Registered: Sep 2009
Location: Washington U.S.
Distribution: M$ Windows / Debian / Ubuntu / DSL / many others
Posts: 2,339

Rep: Reputation: 231Reputation: 231Reputation: 231
Quote:
Originally Posted by linux_walt View Post
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 $$$
 
Old 02-24-2015, 01:12 PM   #2235
LinuxUser42
Member
 
Registered: Nov 2010
Distribution: Lubuntu, Raspbian, Openelec, messing with others.
Posts: 143

Rep: Reputation: 19
Quote:
Originally Posted by linux_walt View Post
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.
 
  


Reply

Tags
64bit, bsd, cloud, linux, microsoft, misinformation, opensource, troll's playground, unix, windows, your words twisted...


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
LXer: Tutorial: Four Easy Fun Useful Things You Can Do With Linux LXer Syndicated Linux News 0 09-30-2008 11:41 PM
LXer: KDE 4: The Shiny New Linux (and Windows) Desktop LXer Syndicated Linux News 0 09-17-2007 06:10 PM
media server or other fun things. doralsoral Linux - Software 1 11-05-2005 07:55 AM
most fun & excited things about Linux woranl Linux - General 2 07-27-2004 08:28 PM

LinuxQuestions.org > Forums > Non-*NIX Forums > General

All times are GMT -5. The time now is 10:41 AM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration