In system management mode, the processor runs code from memory (SMRAM) that can't be seen by the operating system. The usual way of handling this is to map the SMM memory into the address space at 0xa0000 - that is, where the legacy graphics framebuffer is. Normal accesses to this address space are redirected to the graphics card by the northbridge. In SMM, accesses to this address space are diverted to real memory and the magic code is run.
Obviously, it has to be possible for the BIOS to put code their in the first place. There's a configuration flag in the northbridge (on recent Intel chipsets, it's byte 0x9d of the PCI configuration space on the host bridge) that controls whether accesses are directed to the graphics hardware or physical memory. The BIOS can set that to do the initial setup. Once it's done that, the bit is flipped and normal code can no longer see the SMM code. The vulnerability lies in the fact that OS code could reset that bit, gain access to the SMRAM and modify it. Any BIOS I've seen from the past couple of years has gone a step further and set an additional bit that prevents this from occuring. Once that bit is set, the only way for normal code to gain access to the SMRAM region is for the machine to be reset. This happens before any OS code gets run, so there's no opportunity to install hostile SMM handlers.
Is it still possible to exploit? Yes. If the attacker can modify your BIOS they can modify the code that it copies into SMRAM. However, if the attacker can modify your BIOS then they've already won even without using SMM. The initial bootloader uses BIOS calls to read data off disk, so a sufficiently intelligent attack could rewrite that in order to boot a modified kernel. In versions of Windows before Vista, most graphics drivers still made BIOS calls. A modified BIOS could do anything it wanted to with those without looking suspicious in the slightest. Like the article says, it's unlikely that this'll be common. But to be honest, I don't see it happening in the real world at all.
(Today I have been trying to work out just WTF a Dell laptop does when it enters system management mode in response to a brightness hotkey press. The locking down of SMRAM makes this effectively impossible)
I understand that users don't want to have to change their touchpad configuration just because they're using an ALPS pad instead of a Synaptics one. I understand that users would like their Wacom touch screens to work without having to edit xorg.conf. I understand that users don't want to have to configure their hotkeys in order to get them to do anything useful. I understand that users want their laptops to suspend and resume correctly. Those are issues that I understand and have had the time and skills to do something about.
I also understand that users want to be able to play their MP3s, their DIVXs and use their ipods. The reason I do less for these people is that I have very limited time (I have a full-time job that's nothing to do with Linux development). Does that mean I want everything to be done via the CLI? Am I ignoring the needs of users? Do I have a fundamental misunderstanding of what people actually want to use Linux for? No, I don't think so. I just contribute where I can with the resources I have. I'd prefer to be able to solve all of these problems, but I'm limited by actually having to do other stuff with my life.
No, the fact that Automatix has no internal dependency tracking is impossible to fix given the way it's currently implemented. You'd need to rewrite the entire thing. Sure, it might be possible to bring some sections of code from the current version to a decent rewrite - but claiming that that's "fixing" would be like saying your car was "fixed" after being hit by a train just because you've managed to rescue a cupholder from the old one and put it in the new one.
Given that I'm the one who wrote that article, and given that most of the code I've recently written is designed to avoid the need for users to touch the command line, that doesn't seem likely.
That's a restriction on means of distribution, not a restriction on use. You're perfectly welcome to use it with your in-house code, providing that everyone who receives a copy of the binary can have a copy of the source. The additional restrictions to the APSL mean that there's no way to use it if that would result in people being able to breach Apple EULAs.
The fact that the license prohibits you from doing illegal things may not be a problem. However, it also appears to to claim that you may not modify the software in such a way that it allows the circumvention of EULAs. Depending on jurisdiction, there appears to be some degree of uncertainty about whether EULAs are legally enforcable. So, in effect, one of the limitations of this license may be that it prevents you from doing some things that are perfectly legal, but which Apple don't want you to do. It's pretty easy to argue that that sort of restriction prevents it from genuinely being an open source license, in much the same way that a license that said "You may not use this code to produce a Windows version of the product" wouldn't be an open source license.
Note that I'm not passing any sort of judgement on Apple here. It's their code, and they absolutely have the right to do what they want with it. I'm surprised that they feel that unauthorised use of the OS on PCs is sufficiently important that they need to restrict their license terms to make it harder, but, well.
The GPL doesn't limit this sort of thing - you're permitted to use the code for anything, but there are certain limitations on how the resulting work may be distributed. The distinction is subtle, but real.
If the bug's in the firmware, it would be very difficult to exploit it to run code in the kernel. Not impossible, but very difficult. The description of the bug makes it sound extremely like the problem is in the driver, not the firmware.
The fact that you were busy for 8 out of 12 board meetings is semi-justifiable if you had more important things to do, but the fact that you didn't send regrets (which you've apologised for elsewhere) was entirely unjustifiable. I think you can reasonably argue that you felt SPI wasn't high on your list of priorities, but some of your behaviour made it seem like it wasn't on your list of priorities at all. The electorate seemed to agree, and I'm glad you seem to agree that it was probably the right choice.
And everyone's wrong. The only thing that glxgears tells you is how fast glxgears runs. It's astonishingly unrelated to the speed of almost any other 3D application you can run, with the possible exception of the screensaver that's based on the glxgears code.
In the real world, useful applications don't run at 1000FPS. As a result, there's no real need to worry about per-frame overhead. When you're running a game at 30FPS, it's negligable in comparison to the drawing time. When you're running a piece of crappy code that does nothing other than draw spinning gears, that per-frame overhead is suddenly significant and may even dwarf the time spent drawing the application. Does this tell you anything about the speed of your card and drivers? No. Does this let you make comparisons between driver releases? No. Does this let you make comparisons between different drivers? No. It just results in people making unfounded statements about how Y's drivers are 3 times faster than Z's under Linux, when the information provided says nothing of the sort.
glxgears is not a benchmark. Differences in the way the drivers handle synchronisation between frames mean that the limiting factor may be the number of frames per second, not the complexity of the objects drawn.
Going from Xorg 6.7 to 6.8, my glxgears FPS values dropped. My UT ones went up. This ought to tell you something.
It can do that, yes (in the desktop version, you can choose the orientation in the preferences). It doesn't seem to work so well, though. Having the letters approach from the right means you get to read entire words in a fairly natural way. Having them come from above doesn't get you that advantage.
(Yes, it flips to work left to right on left to right languages)
It never really ran acceptable fast on a 400MHz PXA255 (I did the port to the Zaurus, though that wasn't helped by Qtopia's nasty model of having a single input thread running at a low priority - if your input method takes lots of CPU, input events get delayed by up to 2 seconds. Qtopia did more to make me hate Qt than anything else in the world), but again ripping out more of the floating point would have helped that. The older PocketPC port ran much faster on similar hardware, but was effectively an entirely different codebase.
If you grab Dasher CVS right now and build it for a Maemo target (./configure --with-maemo), you'll get something that runs at a just-about usable speed. The floating point has all been removed from Dasher itself, which helps things a great deal (I got about an 8-times speedup from removing a small amount of floating point code - integer maths is pretty much good enough in this case)
The hildon-input-method dynamic library is closed-source
More of a problem. There's currently no API documentation for producing an input application in Maemo, which makes it difficult - ideally, Dasher would be integrated in the same way as the keyboard or handwriting recognition. The other issue is that Dasher makes much better use of vertical screen real-estate than horizontal. On a device like the 770, Dasher would work much better at the side of the screen than at the bottom - and that's something that the libraries just don't support at the moment.
On the plus side, porting Dasher and making it look and feel like a native Maemo application took about 3 hours, including setting up the Scratchbox build environment. Compared to developing for the Zaurus, the 770 is an absolute dream. I'd actually put it ahead of developing for PocketPC, too, despite the lack of a specialised IDE. It's a really nice device for developers, and (despite the occasional obvious lack of performance) it's a much better integrated device than any other small, portable ARM based machine that I've ever used.
So, there's certainly hope for Dasher on the 770 - it's just something that I don't have time to work on at the moment (I'm doing a PhD in genetics right now, so don't have anywhere near as much time to hack on stuff as I'd like to), and Chris has left for the US and h0t chixx0rs (well, possibly only the one). The current performance issues are primarily down to the amount of time taken to draw all the anti-aliased letters, and the simple optimisation of disabling anti-aliasing for them or using Xft directly rather than going through Pango would probably help greatly. Then somebody just has to spend enough time working with Nokia to deal with the input API, convince them to add support for vertical input widgets, rebuild it and things would work beautifully.
If anyone's interested in hacking on it, then check out http://www.inference.phy.cam.ac.uk/dasher/Develop. html and get on the mailing list (Yahoogroups, I'm afraid. Yes, I'm sorry). Someone with enough time could probably get it into a useful state in well under a week.
The T-series Thinkpads are 1.2 inches thick. The 12" powerbook is (according to Apple) 1.18 inches thick, with the 15" one at 1.1 inches. So, uh, no. The older T30 was quite a bit thicker, though.
(When new, my X40 would happily do 7 hours or so on a charge. Of course, that's an ultraportable without an optical drive, but it's also about 2 pounds lighter than a 12" powerbook. The basic moral here is that Apple's hardware is well-designed and fairly good value for money, but it's not magic. Other high-end laptop vendors have hardware that is comparable or better than Apple's, though you tend to pay more money for the better stuff.)
At the time of the previous release, the RT2500 drivers weren't considered stable enough to be included. They are now, and your wlan card should work out of the box in the current preview or the final release due in a couple of weeks.
I guess at one point they managed to get Trusted Debian to change their name, but then Bruce Perens immediately backpedaled with his "fair to all businesses" policy.
You've got the order very wrong there. The Trusted Debian thing happened in 2003, whereas Bruce's policy was announced in 1998.
When Bruce started his little group of people to support Debian, all hell broke loose. A third of the developers went with Bruce to carry on the tradition of separating business from OSS, a third jumped on board with Ubuntu, and the other third just sat around expecting money to fall into their laps.
What little group? The last Debian-related thing Bruce was involved in was Userlinux, which has been a miserable failure. Approximately no Debian developers were involved. A small number of Debian developers (including myself) have some level of involvement in Ubuntu. I don't think we expect to make money out of it, and it doesn't diminish my involvement in Debian. If anyone got involved in Debian in the hope of making money, then they're sadly deluded and I don't seem to have met them yet.
It's not necessarily copyright infringement, but it may be trademark infringement if
(a) Debian held a European trademark before Elektrostore started using that logo, and
(b) A judge could be convinced that the usage is confusing
In this case I doubt that there's any real chance that people could be confused into thinking that Elektrostore are somehow endorsed by or associated with Debian, so it probably wouldn't be a problem for them.
Debian already has a trademark. In the US, it's held by Software in the Public Interest on behalf of Debian. Every page on the Debian website states this in the footer.
This makes me wonder if HP have been directly helping the debian/ubuntu people with ther drivers.
Yes, though the vast majority of this is code that's now integrated into upstream projects.
Mr Garrett recently posted "Go suck on my fuck" on his blog IIRC relating to MJ Ray's retardedness.
No, I didn't. If I'd written that I'd look like some sort of illiterate moron. What I actually said was "choke on my fuck", and I've no regrets about doing so whatsoever.
Slashdot Mirror
In system management mode, the processor runs code from memory (SMRAM) that can't be seen by the operating system. The usual way of handling this is to map the SMM memory into the address space at 0xa0000 - that is, where the legacy graphics framebuffer is. Normal accesses to this address space are redirected to the graphics card by the northbridge. In SMM, accesses to this address space are diverted to real memory and the magic code is run.
Obviously, it has to be possible for the BIOS to put code their in the first place. There's a configuration flag in the northbridge (on recent Intel chipsets, it's byte 0x9d of the PCI configuration space on the host bridge) that controls whether accesses are directed to the graphics hardware or physical memory. The BIOS can set that to do the initial setup. Once it's done that, the bit is flipped and normal code can no longer see the SMM code. The vulnerability lies in the fact that OS code could reset that bit, gain access to the SMRAM and modify it. Any BIOS I've seen from the past couple of years has gone a step further and set an additional bit that prevents this from occuring. Once that bit is set, the only way for normal code to gain access to the SMRAM region is for the machine to be reset. This happens before any OS code gets run, so there's no opportunity to install hostile SMM handlers.
Is it still possible to exploit? Yes. If the attacker can modify your BIOS they can modify the code that it copies into SMRAM. However, if the attacker can modify your BIOS then they've already won even without using SMM. The initial bootloader uses BIOS calls to read data off disk, so a sufficiently intelligent attack could rewrite that in order to boot a modified kernel. In versions of Windows before Vista, most graphics drivers still made BIOS calls. A modified BIOS could do anything it wanted to with those without looking suspicious in the slightest. Like the article says, it's unlikely that this'll be common. But to be honest, I don't see it happening in the real world at all.
(Today I have been trying to work out just WTF a Dell laptop does when it enters system management mode in response to a brightness hotkey press. The locking down of SMRAM makes this effectively impossible)
How do you atomically update more than one file?
I understand that users don't want to have to change their touchpad configuration just because they're using an ALPS pad instead of a Synaptics one. I understand that users would like their Wacom touch screens to work without having to edit xorg.conf. I understand that users don't want to have to configure their hotkeys in order to get them to do anything useful. I understand that users want their laptops to suspend and resume correctly. Those are issues that I understand and have had the time and skills to do something about.
I also understand that users want to be able to play their MP3s, their DIVXs and use their ipods. The reason I do less for these people is that I have very limited time (I have a full-time job that's nothing to do with Linux development). Does that mean I want everything to be done via the CLI? Am I ignoring the needs of users? Do I have a fundamental misunderstanding of what people actually want to use Linux for? No, I don't think so. I just contribute where I can with the resources I have. I'd prefer to be able to solve all of these problems, but I'm limited by actually having to do other stuff with my life.
No, the fact that Automatix has no internal dependency tracking is impossible to fix given the way it's currently implemented. You'd need to rewrite the entire thing. Sure, it might be possible to bring some sections of code from the current version to a decent rewrite - but claiming that that's "fixing" would be like saying your car was "fixed" after being hit by a train just because you've managed to rescue a cupholder from the old one and put it in the new one.
Given that I'm the one who wrote that article, and given that most of the code I've recently written is designed to avoid the need for users to touch the command line, that doesn't seem likely.
That's a restriction on means of distribution, not a restriction on use. You're perfectly welcome to use it with your in-house code, providing that everyone who receives a copy of the binary can have a copy of the source. The additional restrictions to the APSL mean that there's no way to use it if that would result in people being able to breach Apple EULAs.
The fact that the license prohibits you from doing illegal things may not be a problem. However, it also appears to to claim that you may not modify the software in such a way that it allows the circumvention of EULAs. Depending on jurisdiction, there appears to be some degree of uncertainty about whether EULAs are legally enforcable. So, in effect, one of the limitations of this license may be that it prevents you from doing some things that are perfectly legal, but which Apple don't want you to do. It's pretty easy to argue that that sort of restriction prevents it from genuinely being an open source license, in much the same way that a license that said "You may not use this code to produce a Windows version of the product" wouldn't be an open source license.
Note that I'm not passing any sort of judgement on Apple here. It's their code, and they absolutely have the right to do what they want with it. I'm surprised that they feel that unauthorised use of the OS on PCs is sufficiently important that they need to restrict their license terms to make it harder, but, well.
The GPL doesn't limit this sort of thing - you're permitted to use the code for anything, but there are certain limitations on how the resulting work may be distributed. The distinction is subtle, but real.
If the bug's in the firmware, it would be very difficult to exploit it to run code in the kernel. Not impossible, but very difficult. The description of the bug makes it sound extremely like the problem is in the driver, not the firmware.
Ubuntu aren't even making revenue
Untrue.
they're going to get a big contract in 'real soon now'
Already happened.
The fact that you were busy for 8 out of 12 board meetings is semi-justifiable if you had more important things to do, but the fact that you didn't send regrets (which you've apologised for elsewhere) was entirely unjustifiable. I think you can reasonably argue that you felt SPI wasn't high on your list of priorities, but some of your behaviour made it seem like it wasn't on your list of priorities at all. The electorate seemed to agree, and I'm glad you seem to agree that it was probably the right choice.
It looks awfully like a recoloured Cherry G80-3000. The LED design gives it away.
And everyone's wrong. The only thing that glxgears tells you is how fast glxgears runs. It's astonishingly unrelated to the speed of almost any other 3D application you can run, with the possible exception of the screensaver that's based on the glxgears code.
In the real world, useful applications don't run at 1000FPS. As a result, there's no real need to worry about per-frame overhead. When you're running a game at 30FPS, it's negligable in comparison to the drawing time. When you're running a piece of crappy code that does nothing other than draw spinning gears, that per-frame overhead is suddenly significant and may even dwarf the time spent drawing the application. Does this tell you anything about the speed of your card and drivers? No. Does this let you make comparisons between driver releases? No. Does this let you make comparisons between different drivers? No. It just results in people making unfounded statements about how Y's drivers are 3 times faster than Z's under Linux, when the information provided says nothing of the sort.
glxgears is not a benchmark. Differences in the way the drivers handle synchronisation between frames mean that the limiting factor may be the number of frames per second, not the complexity of the objects drawn. Going from Xorg 6.7 to 6.8, my glxgears FPS values dropped. My UT ones went up. This ought to tell you something.
It can do that, yes (in the desktop version, you can choose the orientation in the preferences). It doesn't seem to work so well, though. Having the letters approach from the right means you get to read entire words in a fairly natural way. Having them come from above doesn't get you that advantage.
(Yes, it flips to work left to right on left to right languages)
It never really ran acceptable fast on a 400MHz PXA255 (I did the port to the Zaurus, though that wasn't helped by Qtopia's nasty model of having a single input thread running at a low priority - if your input method takes lots of CPU, input events get delayed by up to 2 seconds. Qtopia did more to make me hate Qt than anything else in the world), but again ripping out more of the floating point would have helped that. The older PocketPC port ran much faster on similar hardware, but was effectively an entirely different codebase.
It runs too slowly.
. html and get on the mailing list (Yahoogroups, I'm afraid. Yes, I'm sorry). Someone with enough time could probably get it into a useful state in well under a week.
If you grab Dasher CVS right now and build it for a Maemo target (./configure --with-maemo), you'll get something that runs at a just-about usable speed. The floating point has all been removed from Dasher itself, which helps things a great deal (I got about an 8-times speedup from removing a small amount of floating point code - integer maths is pretty much good enough in this case)
The hildon-input-method dynamic library is closed-source
More of a problem. There's currently no API documentation for producing an input application in Maemo, which makes it difficult - ideally, Dasher would be integrated in the same way as the keyboard or handwriting recognition. The other issue is that Dasher makes much better use of vertical screen real-estate than horizontal. On a device like the 770, Dasher would work much better at the side of the screen than at the bottom - and that's something that the libraries just don't support at the moment.
On the plus side, porting Dasher and making it look and feel like a native Maemo application took about 3 hours, including setting up the Scratchbox build environment. Compared to developing for the Zaurus, the 770 is an absolute dream. I'd actually put it ahead of developing for PocketPC, too, despite the lack of a specialised IDE. It's a really nice device for developers, and (despite the occasional obvious lack of performance) it's a much better integrated device than any other small, portable ARM based machine that I've ever used.
So, there's certainly hope for Dasher on the 770 - it's just something that I don't have time to work on at the moment (I'm doing a PhD in genetics right now, so don't have anywhere near as much time to hack on stuff as I'd like to), and Chris has left for the US and h0t chixx0rs (well, possibly only the one). The current performance issues are primarily down to the amount of time taken to draw all the anti-aliased letters, and the simple optimisation of disabling anti-aliasing for them or using Xft directly rather than going through Pango would probably help greatly. Then somebody just has to spend enough time working with Nokia to deal with the input API, convince them to add support for vertical input widgets, rebuild it and things would work beautifully.
If anyone's interested in hacking on it, then check out http://www.inference.phy.cam.ac.uk/dasher/Develop
Hunt and peck typing on a simulated keyboard gives you over 30 words per minute? With the same degree of accuracy? Really?
The T-series Thinkpads are 1.2 inches thick. The 12" powerbook is (according to Apple) 1.18 inches thick, with the 15" one at 1.1 inches. So, uh, no. The older T30 was quite a bit thicker, though.
(When new, my X40 would happily do 7 hours or so on a charge. Of course, that's an ultraportable without an optical drive, but it's also about 2 pounds lighter than a 12" powerbook. The basic moral here is that Apple's hardware is well-designed and fairly good value for money, but it's not magic. Other high-end laptop vendors have hardware that is comparable or better than Apple's, though you tend to pay more money for the better stuff.)
At the time of the previous release, the RT2500 drivers weren't considered stable enough to be included. They are now, and your wlan card should work out of the box in the current preview or the final release due in a couple of weeks.
While I agree with a lot of what you're saying:
I guess at one point they managed to get Trusted Debian to change their name, but then Bruce Perens immediately backpedaled with his "fair to all businesses" policy.
You've got the order very wrong there. The Trusted Debian thing happened in 2003, whereas Bruce's policy was announced in 1998.
When Bruce started his little group of people to support Debian, all hell broke loose. A third of the developers went with Bruce to carry on the tradition of separating business from OSS, a third jumped on board with Ubuntu, and the other third just sat around expecting money to fall into their laps.
What little group? The last Debian-related thing Bruce was involved in was Userlinux, which has been a miserable failure. Approximately no Debian developers were involved. A small number of Debian developers (including myself) have some level of involvement in Ubuntu. I don't think we expect to make money out of it, and it doesn't diminish my involvement in Debian. If anyone got involved in Debian in the hope of making money, then they're sadly deluded and I don't seem to have met them yet.
Holding trademarks tends to require you to be a legal entity. Your choices are pretty much:
(a) Debian held a European trademark before Elektrostore started using that logo, and
(b) A judge could be convinced that the usage is confusing
In this case I doubt that there's any real chance that people could be confused into thinking that Elektrostore are somehow endorsed by or associated with Debian, so it probably wouldn't be a problem for them.
Debian already has a trademark. In the US, it's held by Software in the Public Interest on behalf of Debian. Every page on the Debian website states this in the footer.
This makes me wonder if HP have been directly helping the debian/ubuntu people with ther drivers. Yes, though the vast majority of this is code that's now integrated into upstream projects.
No, I didn't. If I'd written that I'd look like some sort of illiterate moron. What I actually said was "choke on my fuck", and I've no regrets about doing so whatsoever.