Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #163058 > unrolled thread

Libre graphics could become the standard if we push right now

Back to article view | Back to linux.debian.user

Contents

  Libre graphics could become the standard if we push right now Alberto Salvia Novella <es20490446e@gmail.com> - 2016-01-14 21:20 +0100
    Re: Libre graphics could become the standard if we push right now deloptes <deloptes@yahoo.com> - 2016-01-14 22:50 +0100
    Re: Libre graphics could become the standard if we push right now Zlatan Todoric <zlatan@riseup.net> - 2016-01-14 23:30 +0100
      Re: Libre graphics could become the standard if we push right now Ric Moore <wayward4now@gmail.com> - 2016-01-15 02:10 +0100
      Re: Libre graphics could become the standard if we push right now Michael Haney <thezorch@gmail.com> - 2016-01-15 02:50 +0100
        Re: Libre graphics could become the standard if we push right now Zlatan Todoric <zlatan@riseup.net> - 2016-01-15 12:10 +0100
          Re: Libre graphics could become the standard if we push right now Alberto Salvia Novella <es20490446e@gmail.com> - 2016-01-15 16:40 +0100
            Re: Libre graphics could become the standard if we push right now Zlatan Todoric <zlatan@riseup.net> - 2016-01-15 17:10 +0100
              Re: Libre graphics could become the standard if we push right now Alberto Salvia Novella <es20490446e@gmail.com> - 2016-01-15 17:20 +0100
                Re: Libre graphics could become the standard if we push right now Joel Rees <joel.rees@gmail.com> - 2016-01-19 13:50 +0100
                  Re: Libre graphics could become the standard if we push right now Alberto Salvia Novella <es20490446e@gmail.com> - 2016-01-19 17:00 +0100
                    Re: Libre graphics could become the standard if we push right now Anders Andersson <pipatron@gmail.com> - 2016-01-19 17:10 +0100
                      Re: Libre graphics could become the standard if we push right now Joel Rees <joel.rees@gmail.com> - 2016-01-20 14:10 +0100
                    Re: Libre graphics could become the standard if we push right now Joel Rees <joel.rees@gmail.com> - 2016-01-20 14:40 +0100
                      Re: Libre graphics could become the standard if we push right now Alberto Salvia Novella <es20490446e@gmail.com> - 2016-01-20 18:40 +0100
                        Re: Libre graphics could become the standard if we push right now Joel Rees <joel.rees@gmail.com> - 2016-01-21 16:00 +0100
                          Re: Libre graphics could become the standard if we push right now Alberto Salvia Novella <es20490446e@gmail.com> - 2016-01-22 17:40 +0100
                            Re: Libre graphics could become the standard if we push right now Joel Rees <joel.rees@gmail.com> - 2016-01-22 19:00 +0100
                            Re: Libre graphics could become the standard if we push right now jdd <jdd@dodin.org> - 2016-01-22 23:20 +0100
                              Re: Libre graphics could become the standard if we push right now Joel Rees <joel.rees@gmail.com> - 2016-01-23 01:30 +0100
                                Re: Libre graphics could become the standard if we push right now Joel Rees <joel.rees@gmail.com> - 2016-01-29 02:20 +0100
                              Re: Libre graphics could become the standard if we push right now <tomas@tuxteam.de> - 2016-01-23 11:20 +0100
                                Re: Libre graphics could become the standard if we push right now Stefan Monnier <monnier@iro.umontreal.ca> - 2016-01-24 05:40 +0100
                                  Re: Libre graphics could become the standard if we push right now <tomas@tuxteam.de> - 2016-01-24 12:30 +0100
      Re: Libre graphics could become the standard if we push right now shawn wilson <ag4ve.us@gmail.com> - 2016-01-15 11:00 +0100
        Re: Libre graphics could become the standard if we push right now Svante Signell <svante.signell@gmail.com> - 2016-01-15 11:40 +0100
        Re: Libre graphics could become the standard if we push right now Zlatan Todoric <zlatan@riseup.net> - 2016-01-15 12:10 +0100
      Re: Libre graphics could become the standard if we push right now Stefan Monnier <monnier@iro.umontreal.ca> - 2016-01-15 15:10 +0100
        Re: Libre graphics could become the standard if we push right now Zlatan Todoric <zlatan@riseup.net> - 2016-01-15 15:50 +0100
    Re: Libre graphics could become the standard if we push right now Paul Johnson <baloo@ursamundi.org> - 2016-01-15 10:00 +0100

Page 1 of 2  [1] 2  Next page →

#163058 — Libre graphics could become the standard if we push right now

[Multipart message — attachments visible in raw view] — view raw

Nearly all compact Linux computers feasible for gaming are sold 
exclusively using NVIDIA graphics, and that company is hostile to libre 
software.

So I think it is very important that we support AMD right now on what we 
can, and ask manufacturers to include AMD graphics in those products.

Because of that I have started campaigning for it:
http://steamcommunity.com/discussions/forum/11/458606248621316073/

[toc] | [next] | [standalone]

#163063

Alberto Salvia Novella wrote:

> Nearly all compact Linux computers feasible for gaming are sold
> exclusively using NVIDIA graphics, and that company is hostile to libre
> software.
> 
> So I think it is very important that we support AMD right now on what we
> can, and ask manufacturers to include AMD graphics in those products.
> 
> Because of that I have started campaigning for it:
> http://steamcommunity.com/discussions/forum/11/458606248621316073/

AMD seems to have one problem or one blessing - its boss.

http://arstechnica.com/business/2013/04/the-rise-and-fall-of-amd-how-an-underdog-stuck-it-to-intel/

[toc] | [prev] | [next] | [standalone]

#163064

On 01/14/2016 09:11 PM, Alberto Salvia Novella wrote:
> Nearly all compact Linux computers feasible for gaming are sold
> exclusively using NVIDIA graphics, and that company is hostile to libre
> software.
> 
> So I think it is very important that we support AMD right now on what we
> can, and ask manufacturers to include AMD graphics in those products.
> 

You do realize that AMD graphics need proprietary firmware to have
proper 3D acceleration without which you probably couldn't run any game
at all - so goodbye Libre graphics.

> Because of that I have started campaigning for it:
> http://steamcommunity.com/discussions/forum/11/458606248621316073/
> 
> 
> 

[toc] | [prev] | [next] | [standalone]

#163073

On 01/14/2016 05:10 PM, Zlatan Todoric wrote:
>
>
> On 01/14/2016 09:11 PM, Alberto Salvia Novella wrote:
>> Nearly all compact Linux computers feasible for gaming are sold
>> exclusively using NVIDIA graphics, and that company is hostile to libre
>> software.
>>
>> So I think it is very important that we support AMD right now on what we
>> can, and ask manufacturers to include AMD graphics in those products.
>>
>
> You do realize that AMD graphics need proprietary firmware to have
> proper 3D acceleration without which you probably couldn't run any game
> at all - so goodbye Libre graphics.
>
>> Because of that I have started campaigning for it:
>> http://steamcommunity.com/discussions/forum/11/458606248621316073/

I don't recall voting for you. Ric


-- 
My father, Victor Moore (Vic) used to say:
"There are two Great Sins in the world...
..the Sin of Ignorance, and the Sin of Stupidity.
Only the former may be overcome." R.I.P. Dad.
http://linuxcounter.net/user/44256.html

[toc] | [prev] | [next] | [standalone]

#163074

[Multipart message — attachments visible in raw view] — view raw

On Thu, Jan 14, 2016 at 4:10 PM, Zlatan Todoric <zlatan@riseup.net> wrote:

>
>
> On 01/14/2016 09:11 PM, Alberto Salvia Novella wrote:
> > Nearly all compact Linux computers feasible for gaming are sold
> > exclusively using NVIDIA graphics, and that company is hostile to libre
> > software.
> >
> > So I think it is very important that we support AMD right now on what we
> > can, and ask manufacturers to include AMD graphics in those products.
> >
>
> You do realize that AMD graphics need proprietary firmware to have
> proper 3D acceleration without which you probably couldn't run any game
> at all - so goodbye Libre graphics.
>
> > Because of that I have started campaigning for it:
> > http://steamcommunity.com/discussions/forum/11/458606248621316073/
> >
> >
>

Uh, excuse me...

https://en.wikipedia.org/wiki/GPUOpen
http://arstechnica.com/information-technology/2015/12/amd-embraces-open-source-to-take-on-nvidias-gameworks/
http://www.tomshardware.com/news/amd-gpuopen-open-source-development,30750.html

It's time we started promoting AMD rather than Nvidia for Linux graphics.

-- 
Michael "TheZorch" Haney
https://sites.google.com/site/thezorch/

"You will not have our hatred, we choose love over fear! Our prayer: we
refuse to become a monster to defeat a monster."
--Bono

Free Your PC, Open Your Mind www.ubuntu.com

[toc] | [prev] | [next] | [standalone]

#163101

[Multipart message — attachments visible in raw view] — view raw

Dropping debian-devel@ from CC (not relevant for discussion, don't know
for Ubuntu ones)

On 01/15/2016 02:28 AM, Michael Haney wrote:
> On Thu, Jan 14, 2016 at 4:10 PM, Zlatan Todoric <zlatan@riseup.net> wrote:
> 
>>
>>
>> On 01/14/2016 09:11 PM, Alberto Salvia Novella wrote:
>>> Nearly all compact Linux computers feasible for gaming are sold
>>> exclusively using NVIDIA graphics, and that company is hostile to libre
>>> software.
>>>
>>> So I think it is very important that we support AMD right now on what we
>>> can, and ask manufacturers to include AMD graphics in those products.
>>>
>>
>> You do realize that AMD graphics need proprietary firmware to have
>> proper 3D acceleration without which you probably couldn't run any game
>> at all - so goodbye Libre graphics.
>>
>>> Because of that I have started campaigning for it:
>>> http://steamcommunity.com/discussions/forum/11/458606248621316073/
>>>
>>>
>>
> 
> Uh, excuse me...
> 
> https://en.wikipedia.org/wiki/GPUOpen
> http://arstechnica.com/information-technology/2015/12/amd-embraces-open-source-to-take-on-nvidias-gameworks/
> http://www.tomshardware.com/news/amd-gpuopen-open-source-development,30750.html
> 
> It's time we started promoting AMD rather than Nvidia for Linux graphics.
> 

So, you just proved what I said. AMD graphics are not free (if you want
a gameplay, for 2D I think you would be fine but...). They were never
free, aren't free and probably will not be free in near future. They
will still have the closed source driver, they said initially they will
be closed source evolving to open source (why evolving, why just not
open source it an be done with it - shady business...) so until that
happens and Radeon (AMDGPU or whatever they call it in the end) drivers
gets FLOSS, your points are not valid.

[toc] | [prev] | [next] | [standalone]

#163112

[Multipart message — attachments visible in raw view] — view raw

Zlatan Todoric:
 > Why just not open source it an be done with it.

Because they need to support old machines that require an unchanged kernel.


Zlatan Todoric:
 > It currently needs closed source firmware to run 3D.

Not firmware, but microcode. It is just how the instruction set is 
handled in the processor, and it is kept confidential because that would 
reveal the hardware design that otherwise would be hard wired.

Even when it would be better libre it cannot restrict how you use your 
computer, be infected by malware, or have a back-door.

[toc] | [prev] | [next] | [standalone]

#163115

On 01/15/2016 04:35 PM, Alberto Salvia Novella wrote:
> Zlatan Todoric:
>> Why just not open source it an be done with it.
> 
> Because they need to support old machines that require an unchanged kernel.
> 
> 
> Zlatan Todoric:
>> It currently needs closed source firmware to run 3D.
> 
> Not firmware, but microcode. It is just how the instruction set is
> handled in the processor, and it is kept confidential because that would
> reveal the hardware design that otherwise would be hard wired.
> 
> Even when it would be better libre it cannot restrict how you use your
> computer, be infected by malware, or have a back-door.
> 
> 

So you started this thread with that subject and now you are defending
them why they have closed source things that we need if we want to
properly use their hardware? And I don't get the last sentence but ok.

[toc] | [prev] | [next] | [standalone]

#163116

[Multipart message — attachments visible in raw view] — view raw

Zlatan Todoric:
 > Now you are defending them why they have closed source things that we
 > need if we want to properly use their hardware?

What I am saying is microcode is more on the hardware side.

Moreover what I am interested in is to set a tendency, rather than on 
things to change overnight.


Zlatan Todoric:
 > I don't get the last sentence but ok.

Firmware is a common concern because it can be overwritten by malware, 
have malicious functionalities, or have back-doors.

That has never been the case with microcode. It just declares the 
instruction set, but is not an executable.

[toc] | [prev] | [next] | [standalone]

#163281

2016/01/16 1:16 "Alberto Salvia Novella" <es20490446e@gmail.com>:
>
> [...]
>
> Firmware is a common concern because it can be overwritten by malware, have malicious functionalities, or have back-doors.
>
> That has never been the case with microcode. It just declares the instruction set, but is not an executable.
>

Just for the record, if microcode can play with the CPU internal
system state, say, the bits that specify whether the CPU is in
supervisor or user state, there's not much to stop, for instance, a
microcode update from providing an undocumented trap to a hidden
routine in the BIOS that does deep packet inspection and arbitrary
forwarding.

As just one way to take advantage of microcode.

--
Joel Rees

Computer memory is just fancy paper,
CPUs just fancy pens.
All is a stream of text
flowing from the past into the future.

[toc] | [prev] | [next] | [standalone]

#163289

[Multipart message — attachments visible in raw view] — view raw

Joel Rees:
> Just for the record, if microcode can play with the CPU internal
> system state, say, the bits that specify whether the CPU is in
> supervisor or user state, there's not much to stop, for instance, a
> microcode update from providing an undocumented trap to a hidden
> routine in the BIOS that does deep packet inspection and arbitrary
> forwarding.

http://security.stackexchange.com/questions/29730/processor-microcode-manipulation-to-change-opcodes

[toc] | [prev] | [next] | [standalone]

#163291

>> Just for the record, if microcode can play with the CPU internal
>> system state, say, the bits that specify whether the CPU is in
>> supervisor or user state, there's not much to stop, for instance, a
>> microcode update from providing an undocumented trap to a hidden
>> routine in the BIOS that does deep packet inspection and arbitrary
>> forwarding.
>
> http://security.stackexchange.com/questions/29730/processor-microcode-manipulation-to-change-opcodes

While we're on the topic of horrible horrible things that I don't want
to think about, and makes me want to move to a cave and run my own
transistor-based CPU:

https://libreboot.org/faq/#microcode

And more generally, secret chipset firmware: https://libreboot.org/faq/#intel

[toc] | [prev] | [next] | [standalone]

#163319

On Wed, Jan 20, 2016 at 12:59 AM, Anders Andersson <pipatron@gmail.com> wrote:
>>> Just for the record, if microcode can play with the CPU internal
>>> system state, say, the bits that specify whether the CPU is in
>>> supervisor or user state, there's not much to stop, for instance, a
>>> microcode update from providing an undocumented trap to a hidden
>>> routine in the BIOS that does deep packet inspection and arbitrary
>>> forwarding.
>>
>> http://security.stackexchange.com/questions/29730/processor-microcode-manipulation-to-change-opcodes
>
> While we're on the topic of horrible horrible things that I don't want
> to think about, and makes me want to move to a cave and run my own
> transistor-based CPU:
>
> https://libreboot.org/faq/#microcode
>
> And more generally, secret chipset firmware: https://libreboot.org/faq/#intel
>

Well, yeah, we've always been somewhat at the mercy of the CPU vendor,
but with billions of on-chip gates to play with, they can and do hide
all sorts of things in there.

Building a CPU out of transistors would be fun, indeed, but it would
eat power like crazy. LS logic would be much more reasonable, and
still not really subject to hidden vulnerabilities other than your own
bugs. I don't think I'd want to build anything beyond a 6809 or maybe
a 6812 that way, and, even there, the power dissipation would be in
the same range as a portable electric heater. Convenient in winter, in
some ways, but you'd have trouble opening up a web page with it.
E-mail, maybe, if you add DMA harware.

Programmable logic is theoretically susceptible to rigging by the
manufacturer, but anything less is not going to be very useful.

-- 
Joel Rees

Be careful when you look at conspiracy.
Arm yourself with knowledge of yourself, as well:
http://reiisi.blogspot.jp/2011/10/conspiracy-theories.html

[toc] | [prev] | [next] | [standalone]

#163320

On Wed, Jan 20, 2016 at 12:55 AM, Alberto Salvia Novella
<es20490446e@gmail.com> wrote:
> Joel Rees:
>>
>> Just for the record, if microcode can play with the CPU internal
>> system state, say, the bits that specify whether the CPU is in
>> supervisor or user state, there's not much to stop, for instance, a
>> microcode update from providing an undocumented trap to a hidden
>> routine in the BIOS that does deep packet inspection and arbitrary
>> forwarding.
>
>
> http://security.stackexchange.com/questions/29730/processor-microcode-manipulation-to-change-opcodes
>

Other than some significant errors in that, how do you interpret it?

It supports neither your peculiar assertion that microcode is not
executable nor your equally peculiar assertion that microcode is not
and has not been a cause for concern.

-- 
Joel Rees

Be careful when you look at conspiracy.
Arm yourself with knowledge of yourself, as well:
http://reiisi.blogspot.jp/2011/10/conspiracy-theories.html

[toc] | [prev] | [next] | [standalone]

#163327

[Multipart message — attachments visible in raw view] — view raw

Joel Rees:
> It supports neither your peculiar assertion that microcode is not
> executable nor your equally peculiar assertion that microcode is not
> and has not been a cause for concern.

Polynomial (http://tinyurl.com/hdtpa7g):
 > Let's assume for a moment that you could overwrite microcode in a
 > useful way. How would you make it do anything useful? Keep in mind
 > that each code simply shifts some values around in the internals of
 > the hardware, rather than a real operation.

Mark Shuttleworth (http://tinyurl.com/pk8zwmv):
 > Declarative firmware that describes hardware linkages and
 > dependencies but doesn’t include executable code is the best chance
 > we have of real bottom-up security.

[toc] | [prev] | [next] | [standalone]

#163379

[Multipart message — attachments visible in raw view] — view raw

2016/01/21 2:33 "Alberto Salvia Novella" <es20490446e@gmail.com>:
>
> Joel Rees:
>
>> It supports neither your peculiar assertion that microcode is not
>> executable nor your equally peculiar assertion that microcode is not
>> and has not been a cause for concern.
>
>
> Polynomial (http://tinyurl.com/hdtpa7g):

You know, a url contains useful information in and of itself. I appreciate
that urls get long and code points out of the basic plane make them hard to
read and encoded server internal indexing really isn't interesting, but at
least it would tell us in this case that what you are taking out of context
is supposed to be from stackexchange.

> > Let's assume for a moment that you could overwrite microcode in a
> > useful way. How would you make it do anything useful?

The poster you are quoting part of does know somewhat about his topic, but
these two sentences together should cause you to think carefully.

Useful is not useful?

Clearly he is thinking of more than one kind of usefulness.

> > Keep in mind
> > that each code simply shifts some values around in the internals of
> > the hardware, rather than a real operation.

If "simply shifting values around in the internals of the hardware" is not
doing any "real" operation, how would the results of any "real operation"
ever get out of the arithmetic or logic units?

Putting an address on the address bus in-and-of-itself neither reads nor
writes data, but putting an address on the address bus is part of both
reading and writing data.

"Modern" CPUs have plenty of spare register space, most of it undocumented.
Register space can be used to record something of state, allowing
instruction streams to be self-parsing.

How many elements of the stuff that enables malware do you want me to point
out? Sure, you're not going to write a backdoor entirely in microcode, but
you can use rogue updates to slip bits and pieces of microcode in to
instructions that allow a backdoor to run and get around the walls.

And not all rogue updates come from 3rd parties.

Read the links Anders posted.

> Mark Shuttleworth (http://tinyurl.com/pk8zwmv):
> > Declarative firmware that describes hardware linkages and
> > dependencies but doesn’t include executable code is the best chance
> > we have of real bottom-up security.

In some ideal world, you could pre-define all the customizations an
integrator or end-user could want in code that gets shipped in the kernel,
and provide a declarative interface to select the tweaks an integrator or
end-user wants.

>From where I stand, it requires the kernel developers to know an awful lot
more about what every possible thing an end user or integrator might want
than is humanly possible.

--
Joel Rees

[toc] | [prev] | [next] | [standalone]

#163456

[Multipart message — attachments visible in raw view] — view raw

Joel Rees:
> "Modern" CPUs have plenty of spare register space, most of it
> undocumented. Register space can be used to record something of state,
> allowing instruction streams to be self-parsing.

Anyway I think this falls mostly in the hardware side. I liked microcode 
to be libre too, but I'm postponing that goal for later. As my main goal 
now is software to be libre.

When libre software is the standard, then I will start talking about 
libre hardware.

Have a nice day.

[toc] | [prev] | [next] | [standalone]

#163462

Just to clarify my participation in this thread --

On Sat, Jan 23, 2016 at 1:34 AM, Alberto Salvia Novella
<es20490446e@gmail.com> wrote:
> Joel Rees:
>>
>> "Modern" CPUs have plenty of spare register space, most of it
>> undocumented. Register space can be used to record something of state,
>> allowing instruction streams to be self-parsing.
>
>
> Anyway I think this falls mostly in the hardware side.

I think you are making an artificial distinction between hardware and
software. That is, you seem to see a bright line where I don't see a
line, and you seem to call some things hardware that I would not.

I still prefer to call ROMmed design elements "firmware", and still
prefer to group firmware with software, making the distinction that
firmware is write-protected by hardware. Other lines of distinction
are generally promoted by salescrews with an axe to grind (proprietary
pseudo-solution to sell).

And the ability to clear the write protection by software makes
firmware infirm, so to speak. Re-writing CPU microcode and BIOS code,
including boot-time drivers and codec definitions, is dangerous, and
shrouding it in secrecy and cryptographic mumbo-jumbo is just the old
sales line of "trust me", which Ken Thompson explained the weakness of
in his classic (and deliberately incomplete) Reflections on Trusting
Trust.

> I liked microcode to
> be libre too,

Sure, microcode should also be free-as-in-freedom. I am definitely not
arguing against that idea.

I'm just saying you seemed to be promoting microcode for something it
can't do, back a ways there.

Your description of microcode as somehow less "executable" and more
"declarative" than something also didn't sit well. (It is both. You
cant separate operation from definition.)

> but I'm postponing that goal for later. As my main goal now is
> software to be libre.

Okay with that, as long as we don't promote the idea of a single
standard solution to graphics.

Monoculture pretty much undoes the advantages of freedom.

> When libre software is the standard, then I will start talking about libre
> hardware.

No problem with your focus on software, although I personally won't
believe we've won much as long as Intel (and now AMD again) and others
hide any kind of code, including the hardware and firmware.

> Have a nice day.

You have a nice day, too.

-- 
Joel Rees

Be careful when you look at conspiracy.
Arm yourself with knowledge of yourself, as well:
http://reiisi.blogspot.jp/2011/10/conspiracy-theories.html

[toc] | [prev] | [next] | [standalone]

#163475

Le 22/01/2016 17:34, Alberto Salvia Novella a écrit :
> libre hardware.
that's far from new

https://en.wikipedia.org/wiki/Open-source_hardware

http://www.gnu.org/philosophy/free-hardware-designs.en.html

I remember efforts done to have free cpu, but I don't think significant 
result have been achieved

I guess the better step is

http://www.excamera.com/files/j1.pdf

but I couldn't find the license for this work

jdd

[toc] | [prev] | [next] | [standalone]

#163481

On Sat, Jan 23, 2016 at 7:15 AM, jdd <jdd@dodin.org> wrote:
> Le 22/01/2016 17:34, Alberto Salvia Novella a écrit :
>>
>> libre hardware.
>
> that's far from new
>
> https://en.wikipedia.org/wiki/Open-source_hardware
>
> http://www.gnu.org/philosophy/free-hardware-designs.en.html
>
> I remember efforts done to have free cpu, but I don't think significant
> result have been achieved
>
> I guess the better step is
>
> http://www.excamera.com/files/j1.pdf

Oh, dear, another FORTH nut.

:)

> but I couldn't find the license for this work
>
> jdd
>

Well, in the pdf for his Euroforth 2010 presentation on his J1
processor, he asserts the BSD license.

I assume he means BSD template, unless he works for UC Berkeley.
Judging from the license in his git repository for SWAPFORTH, it
appears that he does mean BSD template.

I'll have to see if I can contact him, since I'm another FORTH nut, myself.

It looks like the development tools for his processors run on Debian.
Maybe they'll also run on openbsd.

(To make the relevance to the thread explicit, some of the stuff on
Bowman's site, which jdd linked to above, includes examples of a Forth
processor being used as a graphics processor (8 bit). This stuff
really isn't rocket science, guys, no matter how much Intel wants us
to believe it's ever too hard for ordinary people like us to even
bother trying to understand.)

Thanks for the link.

-- 
Joel Rees

Be careful when you look at conspiracy.
Arm yourself with knowledge of yourself, as well:
http://reiisi.blogspot.jp/2011/10/conspiracy-theories.html

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | linux.debian.user

csiph-web