Slashdot Mirror

Powerful hardware isn't necessary when they have eye tracking and foveated rendering. The human eye only sees high resolution in a tiny spot in the center, everything else can be rendered at much lower resolutions.

Secondly: What the hell happened to Nolok?

The same as what happened with the rest of the project, it kind of stalled. There was a lot of development after Milestone1, but that never converged into a finished release and then staled, developers left, new joined, etc., the release now is essentially a snapshot of that incomplete thing with a bit of polish. Nolok is still around and maybe one day I or somebody else will implement it, but there really isn't enough coherence in the development at the moment for that. Here is an animation test from seven years ago.

There's a mailing list email claiming that they were only looking for an address prefixed with facebook and got lucky. Who knows if that's the truth. It still likely took a lot of computing time to get.

Shit, there's been an intro to Linux course out for free for, like, 14 years now: it was written to be self-guided. I know this because, well, I wrote it.

(original announcement )

(...I'm kind of amazed it's still available online, though seeing it in .doc format is kinda funny. Tried to find the original Slashdot announcement, but the search engine on the site sucks.)

If you want to see their status report and plans to address it, see this post from April, 2012 and follow the links:

http://archives.seul.org/or/talk/Apr-2012/msg00068.html

Here's the page to configure a yum repo for the 0.2.4 branch:

https://www.torproject.org/docs/rpms.html.en

They ask that relay nodes run this.

But the problem is that Xpenguins, the most important application to convince your girl friend of Linux does not work with Kwin. So indeed, Linux on the Desktop is a completely lost cause unless these basic features remain unfixed by the KDE team. On the other hand XPenguins works fine with CDE.

SEUL?

I remember they had a huge push to put Linux in schools back in 2000 or so. They also run/host Schoolforge.

I doubt if you have ever seen or used a XO Laptop.

For reference this is how the thing looks with backlight off in normal indoor lighting. Not exactly what I would call usable. Now given, I haven't ever touched a Kindle myself, so I have no idea how good they really are, but all the reports indicate that they are very close to real paper, something the OLPC doesn't even get close to, not even in actual sunlight.

How would you even make 3D the core part of the game? All the 3DS does is give you depth. You could probably build a puzzle platformer where you need depth to tell how to do the next jump, but that is really rather gimmicky and wouldn't work for a lot of games. That aside there isn't really much you can do with 3d, it doesn't give you any additional degrees of freedom as far as the camera is concerned, in fact it takes them away, as you can do longer use the tilt sensor and camera to shift the view around, the fixed viewing position makes such games on the 3DS impossible to do in 3D.

So the problem really isn't the slider, but that depth isn't a gameplay changer, its just additional fidelity, like going from 16bit colordepth to 32bit. Looks a little nicer, but doesn't really change the games you can do.

How would you even make 3D the core part of the game? All the 3DS does is give you depth. You could probably build a puzzle platformer where you need depth to tell how to do the next jump, but that is really rather gimmicky and wouldn't work for a lot of games. That aside there isn't really much you can do with 3d, it doesn't give you any additional degrees of freedom as far as the camera is concerned, in fact it takes them away, as you can do longer use the tilt sensor and camera to shift the view around, the fixed viewing position makes such games on the 3DS impossible to do in 3D.

So the problem really isn't the slider, but that depth isn't a gameplay changer, its just additional fidelity, like going from 16bit colordepth to 32bit. Looks a little nicer, but doesn't really change the games you can do.

People confusing a 1mm cube for a "grain of salt"

A 1mm cube seems to be a pretty good match for a grain of salt and while that is certainly not invisible for the human eye, if you watch it from a meter away you could certainly run into trouble finding it.

Why would there be a "job" listing?

Finding projects that need help is easy, finding projects that have well organized bite-sized tasks that need to be done however is far from easy. And many feature requests might be buried deep down in the bug tracker, making them hard to find for people who might have interest in working on them.

Also the asking part can be troublesome, as it might require extra work on the maintainers side. For Pingus for example I have a very simple task that needs to be done, play through all the currently non-GUI accessible levels, test them, sort them and make them accessible via the GUI. Very basic stuff that doesn't require programming. I explained and walked through at least ten people for that task that offered help, every single one of them just disappeared after a week or two and those that provided contributions where mostly useless (i.e. they just did the grouping, but skipped the far more important testing). All that explaining was just wasted time in which I could have just done it myself. So while a bit communication is of course needed, it is much better for the maintainer when the one offering help already has a really idea of what is going on, instead of having to walked through every tiny step. People that show up "Hey, how can I help" seldom prove useful, people that just come up with "Hey, here is a patch" are much more welcome.

OK How about this : SONY would have been OK with the port, except he didn't leave a way to arbitrarily remove parts of it once customers had acquired them.
Fortunately, there's Pingus for any kind of "Lemmings" fix anyone needs.
While it seems clear that SONY has a legitimate claim in this circumstance, the crap they've pulled previously is not absolved by this case.
SONY doesn't belong in an open market.

[Before Portal officially came to Mac OS X,] could people have legally cloned it, ripped off all the assets, and distributed it for free? I don't even think this is a slippery slope.

The drop-off point is when someone copied the . Under U.S. law, a Portal clone using original assets would fall under the exclusion of game operation methods in 17 USC 102(b), as would Pingus, a Lemmings clone using original assets. The Tetris Company appears not to understand this.

* In using the game brand for their own title?
* Using copyrighted graphics to make their game look the same?

Basically this, if I'm not mistaken. Pretty sure Pingus is legal.

If you saw the video, this guys used all the original graphics, and the trademarked name.

Yup, you could argue that. And if you distributed the port code and required people to extract the artwork from their own copy of Lemmings, you could probably get away with it. If, on the other hand, you distribute all of the original levels and sprites, then you shouldn't be surprised when the owner of the copyright on all of these things complains. Compare this game, for example, with Pingus. In Pingus, the gameplay is similar, but the levels and other artwork are all original.

>"an iPhone version and a Palm Pre [WebOS Linux] version awaiting submission, and free versions for [MS ]Windows and Mac[OS] "

So you are just missing two versions- Android Linux and desktop Linux :) Of course, on desktop Linux, we already have Pingus http://pingus.seul.org/

Photographer vs man with RPG, when the the back half of the image is covered and you only see the silhouette, as in the video, then they look pretty much the same. However it is clear that its a camera,
RPGs are twice as long, you never ever see the "RPG" in full and you never see the "RPG" from any other angle.

The thing I don't understand is why they request permission to engage before they see the RPG, is it enough to kill people to see them walking around with an AK in a non threating pose? Also is it ok to shoot everybody that is near to an insurgent? They don't seem to make any effort to shoot the RPG guy, they just shoot everybody in sight, even the ones that come much later to the scene and never ever have anything on them that could be confused for a weapon.

http://www.acooke.org/andrew/electronics/spice.html- Spice and GEDA tutorial

http://members.dslextreme.com/users/billw/gsch2pcb/tutorial.html-Bill Wilson's tutorial on using gEDA/gaf, gsch2pcb, and PCB

Ugg! These tutorials are completely ancient. I have removed them. Thanks.

The official documentation for the gEDA project can be found here: Official Documentation

Seriously, if you want folks to use gEDA, release a beginner's guide showing how to make something simple, like a fm transmitter or lm317 board, and how to successfully prepare it for sending off to some place like batchPCB.

How about these documents:

• gsch2pcb_tutorial
• gschem_warmup
• transistor_guide
• Getting started with PCB
• ngspice and gschem
• tragesym tutorial
• Circuit Design on Your Linux Box Using gEDA

There is lots of documentation available for using the gEDA suite of tools and the geda-user mailing list is very friendly to all levels of users. I could probably dig up a few more tutorials if the above isn't enough. :)

I've also added a bunch of new free/open source hardware projects to the gEDA links page. There are some really awesome projects listed there that do not use proprietary tools.

http://www.acooke.org/andrew/electronics/spice.html- Spice and GEDA tutorial

http://members.dslextreme.com/users/billw/gsch2pcb/tutorial.html-Bill Wilson's tutorial on using gEDA/gaf, gsch2pcb, and PCB

Ugg! These tutorials are completely ancient. I have removed them. Thanks.

The official documentation for the gEDA project can be found here: Official Documentation

Seriously, if you want folks to use gEDA, release a beginner's guide showing how to make something simple, like a fm transmitter or lm317 board, and how to successfully prepare it for sending off to some place like batchPCB.

How about these documents:

• gsch2pcb_tutorial
• gschem_warmup
• transistor_guide
• Getting started with PCB
• ngspice and gschem
• tragesym tutorial
• Circuit Design on Your Linux Box Using gEDA

There is lots of documentation available for using the gEDA suite of tools and the geda-user mailing list is very friendly to all levels of users. I could probably dig up a few more tutorials if the above isn't enough. :)

I've also added a bunch of new free/open source hardware projects to the gEDA links page. There are some really awesome projects listed there that do not use proprietary tools.

http://www.acooke.org/andrew/electronics/spice.html- Spice and GEDA tutorial

http://members.dslextreme.com/users/billw/gsch2pcb/tutorial.html-Bill Wilson's tutorial on using gEDA/gaf, gsch2pcb, and PCB

Ugg! These tutorials are completely ancient. I have removed them. Thanks.

The official documentation for the gEDA project can be found here: Official Documentation

Seriously, if you want folks to use gEDA, release a beginner's guide showing how to make something simple, like a fm transmitter or lm317 board, and how to successfully prepare it for sending off to some place like batchPCB.

How about these documents:

• gsch2pcb_tutorial
• gschem_warmup
• transistor_guide
• Getting started with PCB
• ngspice and gschem
• tragesym tutorial
• Circuit Design on Your Linux Box Using gEDA

There is lots of documentation available for using the gEDA suite of tools and the geda-user mailing list is very friendly to all levels of users. I could probably dig up a few more tutorials if the above isn't enough. :)

I've also added a bunch of new free/open source hardware projects to the gEDA links page. There are some really awesome projects listed there that do not use proprietary tools.

http://www.acooke.org/andrew/electronics/spice.html- Spice and GEDA tutorial

http://members.dslextreme.com/users/billw/gsch2pcb/tutorial.html-Bill Wilson's tutorial on using gEDA/gaf, gsch2pcb, and PCB

Ugg! These tutorials are completely ancient. I have removed them. Thanks.

The official documentation for the gEDA project can be found here: Official Documentation

Seriously, if you want folks to use gEDA, release a beginner's guide showing how to make something simple, like a fm transmitter or lm317 board, and how to successfully prepare it for sending off to some place like batchPCB.

How about these documents:

• gsch2pcb_tutorial
• gschem_warmup
• transistor_guide
• Getting started with PCB
• ngspice and gschem
• tragesym tutorial
• Circuit Design on Your Linux Box Using gEDA

There is lots of documentation available for using the gEDA suite of tools and the geda-user mailing list is very friendly to all levels of users. I could probably dig up a few more tutorials if the above isn't enough. :)

I've also added a bunch of new free/open source hardware projects to the gEDA links page. There are some really awesome projects listed there that do not use proprietary tools.

http://www.acooke.org/andrew/electronics/spice.html- Spice and GEDA tutorial

http://members.dslextreme.com/users/billw/gsch2pcb/tutorial.html-Bill Wilson's tutorial on using gEDA/gaf, gsch2pcb, and PCB

Ugg! These tutorials are completely ancient. I have removed them. Thanks.

The official documentation for the gEDA project can be found here: Official Documentation

Seriously, if you want folks to use gEDA, release a beginner's guide showing how to make something simple, like a fm transmitter or lm317 board, and how to successfully prepare it for sending off to some place like batchPCB.

How about these documents:

• gsch2pcb_tutorial
• gschem_warmup
• transistor_guide
• Getting started with PCB
• ngspice and gschem
• tragesym tutorial
• Circuit Design on Your Linux Box Using gEDA

There is lots of documentation available for using the gEDA suite of tools and the geda-user mailing list is very friendly to all levels of users. I could probably dig up a few more tutorials if the above isn't enough. :)

I've also added a bunch of new free/open source hardware projects to the gEDA links page. There are some really awesome projects listed there that do not use proprietary tools.

http://www.acooke.org/andrew/electronics/spice.html- Spice and GEDA tutorial

http://members.dslextreme.com/users/billw/gsch2pcb/tutorial.html-Bill Wilson's tutorial on using gEDA/gaf, gsch2pcb, and PCB

Ugg! These tutorials are completely ancient. I have removed them. Thanks.

The official documentation for the gEDA project can be found here: Official Documentation

Seriously, if you want folks to use gEDA, release a beginner's guide showing how to make something simple, like a fm transmitter or lm317 board, and how to successfully prepare it for sending off to some place like batchPCB.

How about these documents:

• gsch2pcb_tutorial
• gschem_warmup
• transistor_guide
• Getting started with PCB
• ngspice and gschem
• tragesym tutorial
• Circuit Design on Your Linux Box Using gEDA

There is lots of documentation available for using the gEDA suite of tools and the geda-user mailing list is very friendly to all levels of users. I could probably dig up a few more tutorials if the above isn't enough. :)

I've also added a bunch of new free/open source hardware projects to the gEDA links page. There are some really awesome projects listed there that do not use proprietary tools.

IMO, what it actually means is that the so-called image is deliberately designed to be as catastrophically horrible as possible when scaled down.

Yes, the image is designed to exploit the bug in way that makes it very obvious that the scaling is wrong, but no, the gray rectangle is not the correct solution. The problem is that the browser or the image application assumes that the brightness is stored on a linear scale, while in reality its stored exponential one. Thus when you scale things or apply other filters the brightness will be messed up. In real photos it will be less noticeable then here, but it will still happen.

The correct way would be to transform the image to a linear scale before applying the filter and then restoring it the exponential one for display. A simple example of how to do that in Gimp (using gausian blur instead of scale, but it is the same bug) would be this. The left image is the original from the article, the middle one is blur applied and the right one is applying a gamma of 0.5 to get it to a linear scale, then the blur and then a gamma 2 to restore it to its original scale. As you can easily see the right one looks like the left one, but blurred, while the middle one has no resemblance to the original, all the information got lost due to the bug. In practice you would need a higher bit depth to make this trick practical, as else you would end with banding artifacts.

Since the news of Tor server(s) being hacked, with the latest version of Tor
as of this posting, v0.2.1.22, the ExcludeNodes function appears to have
been toyed with. Now if you use the ExcludeNodes command in your torrc
configuration file, it doesn't seem to care what node you exclude from
building tor circuits, it will go ahead and use them anyway. But of course,
this is just a bug (suuure it is - having popped up after this so called
hack was done, was it really a hack or a smoke filled backroom agreement?).

Note: Be sure to visit the onionforums .onion board for more discussion

Try it for yourself, add all of the washdc
tor nodes, along with the 149.* nodes and amazon nodes to your ExcludeNodes
listing within your torrc file and within a few hours of your tor surfing,
watch the following so called bug pop up as you are told the nodes you
excluded are being used regardless of your intention to not use them.
This behavior is recent with Tor and I don't consider it a bug, in
my opinion, but an intentional privacy violation. I encourage Tor users
to visit the tor node listings and try this themselves, add as many
nodes as you wish to your ExcludeNodes feature in torrc and reload
tor and surf for hours until the error pops up and it will pop up!
This feature of ExcludeNodes in Tor is now useless and flawed. The
high bandwidth tor nodes should all be considered suspect for reasons
published elsewhere by enlightened individuals documenting potential
and real attacks on onion routing.

http://archives.seul.org/or/talk/Feb-2010/msg00006.html

[warn] Requested exit node 'X' is in ExcludeNodes or ExcludeExitNodes.
Using anyway (circuit purpose Z)

Where X = Node and Z = #. Fingerprints of my chosen nodes to exclude
correctly set within torrc in ExcludeNodes.

Is this a bug?

Why is Tor, when using Bridges, overriding my ExcludeNodes setting?
Was Tor suddenly given Artificial Intelligence? (AI). I assumed
I was under control of my Tor client's functionality with ExcludeNodes.
I guess I should be grateful it reported this to me at all.

- the reply:

On 02/02/2010 02:14 AM, twinkletoedturtle@xxxxxxxxxxxxx wrote:
> Is this a bug?

Yes, https://bugs.torproject.org/flyspray/index.php?do=details&id=1090.
  We're still working on it. In fact, we're working on rewriting the
entire codebase around {Exclude}{Entry|Exit}Nodes options.

--
Andrew Lewman
The Tor Project
pgp 0x31B0974B

Website: https://torproject.org/
Blog: https://blog.torproject.org/
Identi.ca: torproject

Especially when there's unauthorized modifications to addons/plugins BEHIND the backs of the addon authors!

Imagine.. you've gone through all the trouble to properly configure Tor and the Proxy of your choice, only to have the possibility of the plugin itself (Torbutton) modified by someone other than the author and such access could easily provide a vector of attack where a trojan can easily be inserted.

Torbutton is a very popular Firefox addon which makes Tor usage easy.

Read here where the Torbutton author mentions how his Torbutton .xpi release was modified without his consent (and you, the users, download what's been modified AFTER he last modified it!):

http://archives.seul.org/or/talk/Jan-2010/msg00189.html

"Thus spake Paolo Palmieri (palmaway@xxxxxx):

> Sorry, but I have to point out that none of the proposed solution really
> works, and both are actually quite bad from the security point of view.
>
> "Fetch it over SSL" doesn't give the user any guarantee about the
> authenticity of the file. Actually it does little about security. It
> only verifies that the user is connected to the real Tor website, but if
> the file is corrupt or, worse, has been maliciously replaced by some
> malware version of it, you have no means of finding out. Since we are
> talking in this very thread about Tor servers being attacked, I consider
> this as a serious threat.
>
> "Check the git/gpg sig" is a little better, but from a quick look at the
> git repository I couldn't find the .xpi's on it (correct me if I'm wrong
> here). This means that only the sources are signed, thus requiring the
> user to recompile the package at every new release. This is time
> consuming, but it also add some additional requirements on the user,
> like having the right compilation environment on the box, having it
> properly configured etc. All this for no security benefit. Finally,
> checking the git's signature is not as easy as checking a simple .asc file.
>
> So, I have to join Jim's plea. Mike, could you please put the .xpi's
> .asc signature files on the TorButton website?

You're right. I was considering addons.mozilla.org as the canonical
source of the xpi, but still, that can be owned too. In fact, I just
got a message from them informing me that they modified my torbutton
1.2.3 xpi to prevent it from being listed as compatible with FF3.6. So
they see fit to randomly modify the xpis too. Wonder what would happen
if I did have a code signing cert..

I've posted the gpg sigs for 1.2.2, 1.2.3 and 1.2.4 at:
https://www.torproject.org/torbutton/releases/

> P.S. Are git connection to the Tor git's repository protected by TLS
> against a valid certificate?

No. The git:// protocol is not protected. You need to rely on the tag
signatures.

--
Mike Perry
Mad Computer Scientist
fscked.org evil labs"

Roger's entries to date on the subject (excluding first page linked within /. summary):

(this is for those who are too lazy to page through mailing list threads, this post is
missing other individuals replies as well as future replies from Roger and others)

http://archives.seul.org/or/talk/Jan-2010/msg00165.html

Here are some more technical details about the potential impacts, for
those who want to know more about Tor's innards:

----- #1: Directory authority keys

Owning two out of seven directory authorities isn't enough to make a new
networkstatus consensus (you need four for that), but it means you've
only got two more to go. We've generated new v3 long-term identity keys
for these two authorities.

The old v3 long-term identity keys probably aren't compromised, since
they weren't stored on the affected machines, but they signed v3 signing
keys that are valid until 2010-04-12 in the case of moria1 and until
2010-05-04 in the case of gabelmoo. That's still a pretty big window,
so it's best to upgrade clients away from trusting those keys.

You should upgrade to 0.2.1.22 or 0.2.2.7-alpha, which uses the new v3
long-term identity keys (with a new set of signing keys).

----- #2: Relay identity keys

We already have a way to cleanly migrate to a new v3 long-term identity
key, because we needed one for the Debian weak RNG bug:
http://archives.seul.org/or/announce/May-2008/msg00000.html

But we don't have a way to cleanly migrate relay identity keys. An
attacker who knows moria1's relay identity key can craft a new descriptor
for it with a new onion key (or even a new IP address), and then
man-in-the-middle traffic coming to the relay. They wouldn't be able to
spoof directory statements, or break the encryption for further relays
in the path, but it still removes one layer of the defense-in-depth.

Normally there's nothing special about the relay identity key (if you
lose yours, just generate another one), but relay identity keys for
directory authorities are hard-coded in the Tor bundle so the client
can detect man-in-the-middle attacks on bootstrapping.

So we abandoned the old relay identity keys too. That means abandoning
the old IP:port the authorities were listening on, or older clients will
produce warn messages whenever they connect to the new authority. Older
Tor clients can now take longer to bootstrap if they try the abandoned
addresses first. (You should upgrade.)

----- #3: Infrastructure services

Moria also hosted our git repository and svn repository. I took the
services offline as soon as we learned of the breach -- in theory a clever
attacker could give out altered files to people who check out the source,
or even tailor his answers based on who's doing the git update. We're
in pretty good shape for git though: the git tree is a set of hashes
all the way back to the root, so when you update your git tree, it will
automatically notice any tampering.

As explained in the last mail, it appears the attackers didn't realize
what they broke into. We had already been slowly migrating Tor services
off of moria (it runs too many services for too many different projects),
so we took this opportunity to speed up that plan. A friendly anonymous
sponsor has provided a pile of new servers, and git and svn are now up
in their new locations. The only remaining Tor infrastructure services on
moria are the directory authority, the mailing lists, and a DNS secondary.

----- #4: Bridge descriptors

The metrics server had an archive of bridge descriptors from 2009.
We used the descriptors to create summary graphs of bridge count and
bridge usage by country, like the ones you can see at
http://metrics.torproject.

Roger's entries to date on the subject (excluding first page linked within /. summary):

(this is for those who are too lazy to page through mailing list threads, this post is
missing other individuals replies as well as future replies from Roger and others)

http://archives.seul.org/or/talk/Jan-2010/msg00165.html

Here are some more technical details about the potential impacts, for
those who want to know more about Tor's innards:

----- #1: Directory authority keys

Owning two out of seven directory authorities isn't enough to make a new
networkstatus consensus (you need four for that), but it means you've
only got two more to go. We've generated new v3 long-term identity keys
for these two authorities.

The old v3 long-term identity keys probably aren't compromised, since
they weren't stored on the affected machines, but they signed v3 signing
keys that are valid until 2010-04-12 in the case of moria1 and until
2010-05-04 in the case of gabelmoo. That's still a pretty big window,
so it's best to upgrade clients away from trusting those keys.

You should upgrade to 0.2.1.22 or 0.2.2.7-alpha, which uses the new v3
long-term identity keys (with a new set of signing keys).

----- #2: Relay identity keys

We already have a way to cleanly migrate to a new v3 long-term identity
key, because we needed one for the Debian weak RNG bug:
http://archives.seul.org/or/announce/May-2008/msg00000.html

But we don't have a way to cleanly migrate relay identity keys. An
attacker who knows moria1's relay identity key can craft a new descriptor
for it with a new onion key (or even a new IP address), and then
man-in-the-middle traffic coming to the relay. They wouldn't be able to
spoof directory statements, or break the encryption for further relays
in the path, but it still removes one layer of the defense-in-depth.

Normally there's nothing special about the relay identity key (if you
lose yours, just generate another one), but relay identity keys for
directory authorities are hard-coded in the Tor bundle so the client
can detect man-in-the-middle attacks on bootstrapping.

So we abandoned the old relay identity keys too. That means abandoning
the old IP:port the authorities were listening on, or older clients will
produce warn messages whenever they connect to the new authority. Older
Tor clients can now take longer to bootstrap if they try the abandoned
addresses first. (You should upgrade.)

----- #3: Infrastructure services

Moria also hosted our git repository and svn repository. I took the
services offline as soon as we learned of the breach -- in theory a clever
attacker could give out altered files to people who check out the source,
or even tailor his answers based on who's doing the git update. We're
in pretty good shape for git though: the git tree is a set of hashes
all the way back to the root, so when you update your git tree, it will
automatically notice any tampering.

As explained in the last mail, it appears the attackers didn't realize
what they broke into. We had already been slowly migrating Tor services
off of moria (it runs too many services for too many different projects),
so we took this opportunity to speed up that plan. A friendly anonymous
sponsor has provided a pile of new servers, and git and svn are now up
in their new locations. The only remaining Tor infrastructure services on
moria are the directory authority, the mailing lists, and a DNS secondary.

----- #4: Bridge descriptors

The metrics server had an archive of bridge descriptors from 2009.
We used the descriptors to create summary graphs of bridge count and
bridge usage by country, like the ones you can see at
http://metrics.torproject.

It is designed for the old hardware.

http://tiny.seul.org/en/

I prefer marching penguins. (Windows port)

that's three different classes of input "sub"-devices being reported as belonging to that joystick.

Thats already the case, the trouble starts when a game should actually use those. Since then you get into situations where you have a simplistic SNES-like game and somebody wants to have his analog-trigger act as L/R, but the programmer himself used a pad without analog trigger and hasn't bothered to insert the configuration options for the trigger stuff. Or when the programmer used a dpad and thus needed no deadzone, while the gamer wants to use his analogstick and thus needs a deadzone for the thing to function. There are lots of issues that only pop up with this or that gamepad, because they simply are different. When you throw joysticks in the mix it gets even more complicated, since then you stuff like throttle and hats.

If making Linux apps is difficult, it slows down the growth of Linux.

As mentioned before, its not Linux specific, Windows has the exact same problem, many games there don't even bother to support a gamepad at all and force you to keyboard/mouse. Even the PS3 has the problem when you plug in an third-party gamepad into the USB, it sort of works, but most buttons and axis are messed up.

I'm just telling you that it should be easier.

I absolutely agree, getting a gamepad to work currently can be hard. However I just don't see a way to make it work easily and out of the box. Beside xboxdrv I also have inputdrv, which is sort of a universal input event rerouter, if I ever finish that up, it should be able to make games work with pretty much any pad, it however won't be an out of the box. The way its supposed to work is that you have the hardware driver talk to a userspace driver which then transforms the events into something that can be handled by a specific game, so you are basically building up a virtual gamepad for the game to use, instead of letting the game access your gamepad directly.

In the end, while the input system on Linux has a few problems, especially in the upper layers (Xorg, SDL, ...), the lower layer (/dev/input/eventX) are actually quite pretty and simple and Linux also allows you to write user space input driver with which you can fix up basically any game if you really need to.

It's sad really that those joypads have been out for so long and don't work out of the box, when the PS2 and PS3 ones do.

The problem is that Xorg added automatic configuration while not implementing any proper way to override it from the Xorg side. So its not the joypads drivers faults, its Xorg that is the guilty one, it will happily grab all the devices it can find and turn them into a mouse (aka making them unusable), a little HAL config file however can easily fix that permanently.

This is either due to a lack of Linux input standards,

/dev/input/eventX works perfectly fine, the trouble is that dpad comes in a numerous different variants of events, some gamepad have it as first and second axis, in some other it comes much later and thus in not recognized by the games since they only check first and second. Other gamepads report the dpad as buttons, which again doesn't work when the game is looking for an axis. And of course there is SDL, which will report the dpad sometimes as Hat, so even if you have config options for buttons and axis it will not work. If you use some PS2-to-USB adapter things can even more funny, since then two gamepads might end up registering as a single device. And then there is of course the whole deadzone issue, which will screw up some games as well. It happens almost never that a game properly handles all of these cases. This however really isn't a Linux-only problem, gamepads are totally fucked up on Windows as well (to properly use the Xbox360 pad on Windows you have to throw the official driver away and use a homebrew one and the chatpad isn't even support at all). In the end I think the only short time fix is to have an input driver that is actually configurable enough to handle all those situations, which is why I wrote one, its however right know limited to Firestorm pad and Xbox360 gamepads.

it's a lack of an update to the emulators to make them work with the Xinput standards if it actually is a standard.

I don't know any game that actually uses Xinput, most use either the old /dev/input/jsX directly, the new /dev/input/eventX or just a wrapper library like SDL. And just to add a bit of naming confusion, there are actually two Xinput, one is the Xorg input system and the other one is Microsoft new input system mainly used for Xbox360 controller I think, both however are completly unrelated.

Pingus Lemmings clone with penguins!

http://pingus.seul.org/ Uses penguins instead of lemmings. Actually I find it better than lemmings. It does more special tasks for the penguins like jumping, which is really hard to make a penguin jump multiple times while trying to do the same for his other penguin buddies. Installs on windows, osx, and linux. It has its own level editor so you can make as many boards as you want but from the default it has way more than any single version of lemmings did.

http://geda.seul.org/ looks interesting as a solution to the $1000+ software. I'm not sure if it's capable of doing what you ask with openmoko, but I'm sure it can work with many projects. The conversion and debugging would be a labour of love for a hobbyist which would negate many of the associated costs, and once one hobbyist shares it, the gap disappears. Can't you just be happy that the potential is there, even if it costs $25,000? Designing from scratch would entail a far greater cost.

A good number of these projects are using non-free schematic capture and/or layout packages. What if I want to modify the schematics or layouts? Do I have to redraw them in one of the real free/open source tools?

Eagle is not free software (there is no source code and the "free" download is crippleware since the board size is limited).

PS. Yes I'm slightly bias as I am a developer on gEDA http://geda.seul.org/ and KiCad is nice too. :)

Try Pingus. It's a free lemmings clone covered by the GNU GPL. http://pingus.seul.org/

The gEDA project has been using git for almost two years, having migrated from CVS. Due to the maintainer of the project having very little time to spend on 'pulling' trees from the various developers, we chose to use a hybrid model, where authorised developers push the changes from their personal repositories into a single 'main' repository.

The primary advantages we saw were:

1. Changesets, to track changes occurring together (also available in SVN).
2. The ability to give every developer a sandbox which they can work in privately, with very very cheap branches for trying out experimental stuff.
3. Tools like stgit to massive improved the quality, clarity and organisation of patches being committed.
4. Fully-featured offline working.
5. Even those without 'commit access' can use all of the features of the SCM.

We would never go back to using a centralised-model SCM.

As far as git vs. hg is concerned: meh. Both have advantages and disadvantages, but to me they mostly seem superficial.

Gits biggest problems are: Almost total lack of tool integration into existing tools.

The Emacs integration works perfectly for me!

You have a load of data which resides on your filesystem (basically a full repo copy) while SVN keeps only parts of the metadata locally.

This is actually a good thing when you're on the train without internet access and you want to work out how a bug cropped up.

The gEDA project switched to git almost two years ago (at my instigation), and the maintainer has said that he would never, ever go back to a centralized SCM.

Why create entirely different "line", "rectangle", "polygon", and "ellipse" tools when "stroke selection" and "stroke path" do all of those -- and more?

For one reason because they don't. Stroking a selection gives a rather ugly circles compared to a real circle tools, since to much information gets lost along the way. And of course also usability, lack of proper circle tools has been an issue for a decade and yet it is still not fixed and still continues to be an issue and the issue won't go away by pretending its not there. Name a good reason why Gimp shouldn't have a set of geometry tools. I frankly can't think of one. If somebody worries that the toolbox is getting crammed, just add a way to remove tools from it.

All that aside, there is also a larger issue with the lack of those tools, namely that tools can't be plug-ins, so any new tool has to be done directly in Gimp and can't be supplied as an add-on. If they could be this issue would have already been fixed long ago.

Why create entirely different "line", "rectangle", "polygon", and "ellipse" tools when "stroke selection" and "stroke path" do all of those -- and more?

For one reason because they don't. Stroking a selection gives a rather ugly circles compared to a real circle tools, since to much information gets lost along the way. And of course also usability, lack of proper circle tools has been an issue for a decade and yet it is still not fixed and still continues to be an issue and the issue won't go away by pretending its not there. Name a good reason why Gimp shouldn't have a set of geometry tools. I frankly can't think of one. If somebody worries that the toolbox is getting crammed, just add a way to remove tools from it.

All that aside, there is also a larger issue with the lack of those tools, namely that tools can't be plug-ins, so any new tool has to be done directly in Gimp and can't be supplied as an add-on. If they could be this issue would have already been fixed long ago.

xorg.conf needs to go away

I personally find xorg.conf easier to configure. However, it is being replaced by HAL.

Frankly, I don't need to be able to connect remotely to my xorg server, and most people don't need to either

So you want to remove the server from the server? I wonder how much code you would lose by telling X to ignore the network. Personally, I use this functionality all the time. However, if you only have a single computer that you never need to access remotely, at least at the GUI level, I can see the desire to remove the feature.

Xorg should auto-failback to a VGA/VESA mode like Windows.

I found this approach interesting: http://archives.seul.org/or/cvs/Sep-2007/msg00180.html If X fails on the first server layout, have it fall back to the second.

Xorg needs to step into the 21st century when it comes to multi-monitors and multi-GPUs

I admit that I haven't used X in a multi-GPU setup. However, xrandr seems to work fine with multiple monitors. I use KDE's KRandRTray all the time with dual-monitor setups, projectors, and televisions.

A real basic X windowing environment would benefit most users

Have you considered KDrive or XDirectFB?

It appears that the Tor network is also compromised by this bug:

http://archives.seul.org/or/announce/May-2008/msg00000.html

IMPACT:
    A local attacker or malicious directory cache may be able to trick
    a client running 0.2.0.x into believing a false directory consensus, thus
    (e.g.) causing the client to create a path wholly owned by the attacker.

    Further, relay identity keys or hidden service secret keys that were
    generated on most versions of Debian, Ubuntu, or other Debian-derived OS
    are also weak (regardless of your Tor version):
        http://lists.debian.org/debian-security-announce/2008/msg00152.html

Given that Tor is relied on in some pretty scary places (China, etc.), I wonder if anyone will get killed because of this.

Hi, For those students with Electrical Engineering interests, check out the gEDA project. This deadline extension is quite nice as there are still lots of interesting projects for students to work on. :) -Ales

Hi, For those students with Electrical Engineering interests, check out the gEDA project. This deadline extension is quite nice as there are still lots of interesting projects for students to work on. :) -Ales

The gEDA project was accepted again this year (second year we are participating). We are quite thrilled and grateful to Google for the opportunity! We are looking for students who are interested in working on free software and electronic circuit design software.

Here is gEDA's GSoC 2008 page as well as the suggested projects page. You can also look at gEDA's homepage for more info on the project in general.

The gEDA project was accepted again this year (second year we are participating). We are quite thrilled and grateful to Google for the opportunity! We are looking for students who are interested in working on free software and electronic circuit design software.

Here is gEDA's GSoC 2008 page as well as the suggested projects page. You can also look at gEDA's homepage for more info on the project in general.

The gEDA project was accepted again this year (second year we are participating). We are quite thrilled and grateful to Google for the opportunity! We are looking for students who are interested in working on free software and electronic circuit design software.

Here is gEDA's GSoC 2008 page as well as the suggested projects page. You can also look at gEDA's homepage for more info on the project in general.

The Linux-style "give it away for free" approach simply doesn't work for programs that are (a) very complex and (b) not widely used. I'm thinking of music composing, CAD, EDA and 3D design tools here.

You are wrong. Take Ardour or gEDA for example. I'm sure you will point out how unsophisticated these are compared to their commercial counterparts, but these programs are quite functional and suitable for 75% of what people need to do. If there were no commercial software counterparts to these, you'd better believe the companies that needed the software would contribute resources to seeing that the free versions did what they needed them to do.

In fact, I'd argue that it is because of commercial software that the free versions lag behind. If a company can buy a program for $10k, they have no motivation to see that the free version is improved. They might not even want to see the free version improved because the high cost serves as an entry barrier into the field to help keep out competitors.

My point here is that if this truly is the information age, then we must have the notion of information as property.

Unsubstantiated bullshit.

Even free software programmers are affected, since IP law also protects their work from being stolen (GPL violations, etc.).

I loathe people who make this specious argument. If there were no copyrights, there would never have been a need for the GPL in the first place. There's a reason it's referred to as "copyleft" license; it's a direct attack on the evils of copyright.