I'd just like to point out the Nooks extension isn't a microkernel (it's "just" an extension to Linux). Is your point that Nooks won't catch enough errors and that microkernels will take over as a result? That doesn't seem right given your earlier SCSI and AGP comments though (however, I am going to argue that major subsystems aren't going to be where most of the bugs are - most bugs are in the drivers (go on make a reply talking about drivers locking up the bus;))
Don't mean to be facetious, but the micro-kernel has very little to do with the security of the OS.
Well I do mean to be pedantic because doesn't "the security of the OS" with respect to micro vs monolithic kernels depend on your definition of OS?
If you meant kernel then I would say microkernels have a chance of being even more secure than monolithic ones assuming all other things are equal because any given error is more likely to be confined in a place where it can do less damage when compared to a monolithic kernel. So I'd say it has a sizeable role in security.
If you meant OS as in "kernel and base userland utilities" then I'd argue things like code security audits and ideas like SELinux would play a big role because you are now mitigating non-root user security problems too. Even so I'd say kernel security still plays more than a "very little" role in OS security.
First up SELinux is really for userspace not the kernel (I'm fairly sure once loaded drivers aren't affected by SELinux). Secondly SELinux isn't so much a set of compartments but rather a set restrictions saying in a fine grained way what a program should and shouldn't be doing down to seemingly a syscall level, who it's allowed to talk to and so on. I'd argue it goes beyond mere isolation...
I agree with the previous comment. Memory that has gone bad, memory being run at a speed it can't cope with, overclocked machines, undercooled machines, overstretched PSUs etc all cause weird and intermittent problems (see this Linux kernel developer's note on hardware that results in weird problems). If you are binary driver free and still having strange intermittent lockups I'd definitely test the memory for a day with Memtest and start swapping bits of hardware out.
I'm going to weigh in over here mainly becuase my quiet slumber in the minix newsgroup has been disturbed by a call to arms from ast to correct some of the FUD here on Slashdot.
Drivers have measurably more bugs in them than other parts of the kernel. This has been shown by many studies (see the third reference in the article). This can also been shown empirically - modern versions of Windows are often fine until a buggy driver gets on to them and destablises things. Drivers are so bad that XP even warns you about drivers that haven't been through checks. Saying people should be careful just doesn't cut it and is akin to saying people were more careful in the days of multitasking without protected memory. Maybe they were but some program errors slipped through anyway, bringing down the whole OS when I used AmigaOS (or Windows 95). These days, if my my web browser misbehaves at least it doesn't take my word processor with it, losing the web browser is pain enough.
In all probability you would know that a driver had to be restarted because there's a good chance its previous state had to be wiped away. However a driver that can be safely restarted is better than a driver that locks up everything that touches it (ever had an unkillable process stuck in the D state? That's probably due to a driver getting stuck). You might be even able to do a safe shutdown and lose less work. From a debugging point of view I prefer not having to reboot the machine to restart the entire kernel when driver goes south - it makes inspection of the problem easier.
(Just to prove that I do use Minix though I shall say that killing the network driver results in a kernel panic which is a bit of a shame. Apparently the state is too complex to recover from but perhaps this will be corrected in the future).
At the end of the day it would be better if people didn't make mistakes but since they do it is wise to take steps to mitigate the damage.
Stable API only helps out of tree drivers
on
The SLI Godfather
·
· Score: 2, Insightful
It can be argued that fixed APIs will hurt the kernel itself as the amount of glue code to keep old things poking at the internals rises along with the need to never change things causes unintended side effects.
I was chatting to Linux kernel developer about a year ago and he described how in the early 90s he found a remote security hole in a closed source operating system. He let the vendor know but the vendor did not patch the hole for over a year. To fix the hole the vendor had to change the API (which of course was set in stone) which would break all sorts of other things so the problem sat around unfixed until the next major release of the operating system.
The number one reason for running an out of tree driver on Linux is because it is a binary driver. And there are Linux developers who don't want to help binary driver developers. The prerogative is with the Linux devs - it's their kernel and perhaps it is those very open drivers that are keep said developers working on it. Secretly, I think you need the resources of Microsoft to produce APIs that don't change for years on end and support a large range of software but I'm told the NetBSD folks do this too. Why don't people simply use NetBSD rather than complaining?
Was OpenBSD really first with OSS nvidia ethernet?
on
The SLI Godfather
·
· Score: 2, Informative
Are you sure that you want to claim that OpenBSD had "the first [nforce ethernet] open source driver" (emphasis is mine)? Can you give some links to back this claim up? I haven't found any yet but then again I don't hang out on the OpenBSD lists all that much...
I meant 10 minutes in reference to your "it took 10 minutes to fix the HTML" when I said I thought it would take more than 5 so I didn't bother.
I'm convinced you can work around the problem using one level nested divs and it should work in most browsers but as usual that may bring its own problems.
Why no magic centre method? I gues because it would conflict with the existing attributes (what happens when you have margins AND centring?!). It is there for plain old text though (which doesn't have margins).
"If 'left' has the value 'auto' while 'direction' is 'ltr', replace 'auto' with the distance from the left edge of the containing block to the left margin edge of a hypothetical box that would have been the first box of the element if its 'position' property had been 'static'."
We can read that as saying the "left becomes where the inside box's left edge is under more normal conditions" (I could be wrong though but I think that's the only sensible interpretation). Now here's that "but" you were expecting:
"(But rather than actually computing that box, user agents are free to make a guess at its probable position.)"
Browsers are *allowed* to guess at where it would have gone. Thanks to this, a guess that doesn't match up with where it would have been isn't actually wrong - it's just not what you would have wanted. So Opera is guessing wrong (it "guesses" right with actual values in the margins) but this is actually allowed by the spec.
I don't have the testcase to hand but basically it had one div in it. Now to ensure the right thing happened I would nest a div inside that one div and move the position: fixed (and any borders or background colours etc.) to that inner one. In tests that did what I was expecting because the left edge was already in the right place.
Summary, your code is (I use this word reservedly given some of the hacks) "right" it's just that there's more than one answer...
... it's going to take me more than 5 minutes to fix up all those HTML validation errors - sorry.
While your page has HTML errors (like poorly nested tags) it's hard to know whether it is those very same HTML errors that are causing layout issues. More often than not it is, making people very reluctant to go to the effort of debugging a page until they are all fixed. When your markup validates you are far more likely to be able to pique people's interest that you have found a browser bug because it is one (or in this case 47) less thing to check.
If you DO manage to get that page to validate and still see the problem you might want to ask again though...
It could be that your particular problem isn't seen by anyone else (they may have similar but subtley different kit and not see the problem). If you wander off and no one else mentions it the odds are when you come back in six weeks the problem will still be there (hint: looking at the HP Laptop Support page no one has mentioned the problem on your laptop model).
While it may be daunting, your best chance of having this fixed quickly is to head over and file a useful bug report (e.g. Description of the problem, simple step by step instructions indicating the lead up to the bug, what you expected to happen and what actually happened) over on Launchpad.
Isn't apt-get install build-essential the usual way to get the minimal libraries/headers/programs for when you wish to have a basic build environment on a Debian based distro?
Hi there, I've seen this mentioned before in comments on other sites but I've never seen an authorative source mentioning this. Is there any chance you can post a link to an offical Mandriva/Thompson spokeperson mentioning this? My (old) understanding was that many years ago they were shipping MP3 support without a licence...
Remember folks: Slashdot isn't your distro's bug tracker. Complaining here may give your issue exposure but it probably won't help your bug to be fixed. Please, please report bugs in your distro to your distro's bug tracker. There's no guarantee that your issue will ever be fixed but your odds are vastly improved...
Xorg isn't licenced under GPL, it's mostly BSD / MIT (apart from things like fonts). Since Xgl is part of Xorg it too is under an MIT style licence. Being GPL would make things like binary drivers legally very dubious.
I've been using it for weeks. It has noticible bugs. Compiz (the compositing manager that lets you actually do a lot of the cool stuff) has bugs / lacks some of the good behavior of other window managers. Without the right extensions in your drivers it can be much slower in mundane operations than Xorg (e.g. video on cards/drivers without shader support). It's missing features (resizing the screen for games). It's exposed (new) nvidia driver bugs that take down X. Pressing shift-backspace kills the server (and any work that was on it). Not all 3D cards/drivers like it.
If you aren't the sort who knows (or wants to learn) how to file useful bug reports (with accurate information - i.e. "it's broken" doesn't cut it) and / or fix the code yourself I wouldn't try it for anything more than a few minutes.
It's probably your drivers to blame because I've heard similar reports from other ATI laptop users. Alas the closed ATI drivers seem to have a reputation for instablility and it can't be the cards fault because I'm told they are extremly stable under Windows/OS X. 'Tis a shame, but I guess there's not much of a business case to pour a ton of money into fixing 99% of the problems because the Linux 3D market is tiny.
Tough call. I'm going to say no for Voodoo's older than V3 due to the lack of DRI. For Voodoos V3-5 I'm going to say maybe not due to unimplemented features in the 3dfx driver. I'm basing this on information from the AIGLX project which is similar but different to Xgl so this could be wide of the mark.
However last I heard Xgl was trying to target OpenGL 1.3 (or 1.2 with a particular extension). If your driver doesn't implement those features you could be out of luck...
Your graphics driver doesn't yet support the GLX_EXT_texture_from_pixmap extension so every time that call is made (near enough any time the window changes) it is going to be emulated in software. As you do that opaque resize just think how many times it might be being called... Don't worry though - your 3D chipset vendor says they will implement it in their next driver release.
However at the end of the day what is acceptable to me could well not be acceptable to you - just two months ago everyone was complaining window dragging was too slow whereas I thought it was acceptable. On Xgl it seems quite fast to me but now we're on to the next of the never ending issues. I guess since you want something finished yesterday you had better start saving for / using that Mac...
I'm rather doubtful that platform matters when doing Google searches. Are you aware that Google has several different data centres around the world that do not always return exactly the same results? Also Google *does* show different results depending on whether you are using a localised Google or not, what preferences you have set (e.g. only return English pages) or whether you are using a themed Google (e.g. Google Linux).
You never know though. Do you have any solid repeatable data (e.g. using proxies and ensuring your searches are going to the same data centre) to prove that the platform does affect results?
I haven't been able to check the veracity of this but one of the comments hints at what Doug went on to do and why (the anchor link seems broken in Firefox, it's the comment that starts "Wow, except for the two obviously disgruntled stock market guys" by Frank Gilroy)...
I assume it's the European counterpart to the T1, T1s in the US are a lot cheaper, like 2% of that cost.
There's no need to guess when you can check. A quick gander at wikipedia or google define says that an E1 offers 2.048 Mbit/s of bandwidth whereas a T1 offers 1.544 Mbit/s. However your cost point is taken since an E1 obviously isn't 50 times the speed T1...
If memory serves, most of these home routers are running on MIPS based hardware. There is no port of OpenBSD to the sbmips platform (yes there is an SGI MIPS port but I doubt it is similar enough for an easy transition). I believe NetBSD has been ported to this platform but I am unsure of whether the supported chipset is the same as that in a home router. There's also the possiblity that there won't be wifi card or ethernet drivers on NetBSD so you would have to reverse engineer those... Personally I'd just stick with Linux but porting a *BSD for full support would be an interesting exercise.
As another poster said, if you want to run OpenBSD on embedded hardware you are better off going for the soekris stuff but you'll pay a LOT more (prices for just the board without case, wifi card or power cable start at $128) than for the shelf consumer stuff (Amazon has a WRT54 for $54.99).
If you check the beginning ofthe 2.6.14 changelog you will find mention of a "ieee80211 subsystem" being merged. So hopefully all drivers will be ported to the generic in kernel 802.11 stack. This will hopefully take over WPA crypto duties from drivers. This also goes hand in hand with version 28 of Wireless Tools which will provide a basic (but standard) interface for WPA.
Yes the *BSDs are further down this track as pointed out in another comment buy it's nice to see Linux catching up and I believe HostAP and the Centrino drivers have already been converted over to using the generic 802.11 stack.
Slashdot Mirror
Minix runs on Xen (and Xen can be part of Linux).
I'd just like to point out the Nooks extension isn't a microkernel (it's "just" an extension to Linux). Is your point that Nooks won't catch enough errors and that microkernels will take over as a result? That doesn't seem right given your earlier SCSI and AGP comments though (however, I am going to argue that major subsystems aren't going to be where most of the bugs are - most bugs are in the drivers (go on make a reply talking about drivers locking up the bus ;))
Well I do mean to be pedantic because doesn't "the security of the OS" with respect to micro vs monolithic kernels depend on your definition of OS?
If you meant kernel then I would say microkernels have a chance of being even more secure than monolithic ones assuming all other things are equal because any given error is more likely to be confined in a place where it can do less damage when compared to a monolithic kernel. So I'd say it has a sizeable role in security.
If you meant OS as in "kernel and base userland utilities" then I'd argue things like code security audits and ideas like SELinux would play a big role because you are now mitigating non-root user security problems too. Even so I'd say kernel security still plays more than a "very little" role in OS security.
First up SELinux is really for userspace not the kernel (I'm fairly sure once loaded drivers aren't affected by SELinux). Secondly SELinux isn't so much a set of compartments but rather a set restrictions saying in a fine grained way what a program should and shouldn't be doing down to seemingly a syscall level, who it's allowed to talk to and so on. I'd argue it goes beyond mere isolation...
I agree with the previous comment. Memory that has gone bad, memory being run at a speed it can't cope with, overclocked machines, undercooled machines, overstretched PSUs etc all cause weird and intermittent problems (see this Linux kernel developer's note on hardware that results in weird problems). If you are binary driver free and still having strange intermittent lockups I'd definitely test the memory for a day with Memtest and start swapping bits of hardware out.
I'm going to weigh in over here mainly becuase my quiet slumber in the minix newsgroup has been disturbed by a call to arms from ast to correct some of the FUD here on Slashdot.
Drivers have measurably more bugs in them than other parts of the kernel. This has been shown by many studies (see the third reference in the article). This can also been shown empirically - modern versions of Windows are often fine until a buggy driver gets on to them and destablises things. Drivers are so bad that XP even warns you about drivers that haven't been through checks. Saying people should be careful just doesn't cut it and is akin to saying people were more careful in the days of multitasking without protected memory. Maybe they were but some program errors slipped through anyway, bringing down the whole OS when I used AmigaOS (or Windows 95). These days, if my my web browser misbehaves at least it doesn't take my word processor with it, losing the web browser is pain enough.
In all probability you would know that a driver had to be restarted because there's a good chance its previous state had to be wiped away. However a driver that can be safely restarted is better than a driver that locks up everything that touches it (ever had an unkillable process stuck in the D state? That's probably due to a driver getting stuck). You might be even able to do a safe shutdown and lose less work. From a debugging point of view I prefer not having to reboot the machine to restart the entire kernel when driver goes south - it makes inspection of the problem easier.
(Just to prove that I do use Minix though I shall say that killing the network driver results in a kernel panic which is a bit of a shame. Apparently the state is too complex to recover from but perhaps this will be corrected in the future).
At the end of the day it would be better if people didn't make mistakes but since they do it is wise to take steps to mitigate the damage.
It can be argued that fixed APIs will hurt the kernel itself as the amount of glue code to keep old things poking at the internals rises along with the need to never change things causes unintended side effects.
I was chatting to Linux kernel developer about a year ago and he described how in the early 90s he found a remote security hole in a closed source operating system. He let the vendor know but the vendor did not patch the hole for over a year. To fix the hole the vendor had to change the API (which of course was set in stone) which would break all sorts of other things so the problem sat around unfixed until the next major release of the operating system.
The number one reason for running an out of tree driver on Linux is because it is a binary driver. And there are Linux developers who don't want to help binary driver developers. The prerogative is with the Linux devs - it's their kernel and perhaps it is those very open drivers that are keep said developers working on it. Secretly, I think you need the resources of Microsoft to produce APIs that don't change for years on end and support a large range of software but I'm told the NetBSD folks do this too. Why don't people simply use NetBSD rather than complaining?
Look I'm an OpenBSD fan but even I'm a little unsure on this one... The Linux folks reverse engineered the Nvidia ethernet driver in forcedeth and in fact forcedeth was helpful in the creation of nfe.
Are you sure that you want to claim that OpenBSD had "the first [nforce ethernet] open source driver" (emphasis is mine)? Can you give some links to back this claim up? I haven't found any yet but then again I don't hang out on the OpenBSD lists all that much...
I meant 10 minutes in reference to your "it took 10 minutes to fix the HTML" when I said I thought it would take more than 5 so I didn't bother.
I'm convinced you can work around the problem using one level nested divs and it should work in most browsers but as usual that may bring its own problems.
Why no magic centre method? I gues because it would conflict with the existing attributes (what happens when you have margins AND centring?!). It is there for plain old text though (which doesn't have margins).
WRT to your CSS: orange isn't a valid color! : ) (sits down and breaks apart page...)
The centring problem can be boiled down to the following:The rules over how the distance for the left edge is calculated in this case are fairly complicated. Here's what point 1 says:
We can read that as saying the "left becomes where the inside box's left edge is under more normal conditions" (I could be wrong though but I think that's the only sensible interpretation). Now here's that "but" you were expecting:
Browsers are *allowed* to guess at where it would have gone. Thanks to this, a guess that doesn't match up with where it would have been isn't actually wrong - it's just not what you would have wanted. So Opera is guessing wrong (it "guesses" right with actual values in the margins) but this is actually allowed by the spec.
I don't have the testcase to hand but basically it had one div in it. Now to ensure the right thing happened I would nest a div inside that one div and move the position: fixed (and any borders or background colours etc.) to that inner one. In tests that did what I was expecting because the left edge was already in the right place.
Summary, your code is (I use this word reservedly given some of the hacks) "right" it's just that there's more than one answer...
HTH
... it's going to take me more than 5 minutes to fix up all those HTML validation errors - sorry.
While your page has HTML errors (like poorly nested tags) it's hard to know whether it is those very same HTML errors that are causing layout issues. More often than not it is, making people very reluctant to go to the effort of debugging a page until they are all fixed. When your markup validates you are far more likely to be able to pique people's interest that you have found a browser bug because it is one (or in this case 47) less thing to check.
If you DO manage to get that page to validate and still see the problem you might want to ask again though...
It could be that your particular problem isn't seen by anyone else (they may have similar but subtley different kit and not see the problem). If you wander off and no one else mentions it the odds are when you come back in six weeks the problem will still be there (hint: looking at the HP Laptop Support page no one has mentioned the problem on your laptop model).
While it may be daunting, your best chance of having this fixed quickly is to head over and file a useful bug report (e.g. Description of the problem, simple step by step instructions indicating the lead up to the bug, what you expected to happen and what actually happened) over on Launchpad.
Isn't
apt-get install build-essential
the usual way to get the minimal libraries/headers/programs for when you wish to have a basic build environment on a Debian based distro?
Hi there, I've seen this mentioned before in comments on other sites but I've never seen an authorative source mentioning this. Is there any chance you can post a link to an offical Mandriva/Thompson spokeperson mentioning this? My (old) understanding was that many years ago they were shipping MP3 support without a licence...
Normally I'd ask whether a bug report has been filed on this but I happen to know there's a launchpad bug about the 2G/2G kernel option breaking WINE and Lisps. You're in luck too - a fix for the problem was released two days ago.
Remember folks: Slashdot isn't your distro's bug tracker. Complaining here may give your issue exposure but it probably won't help your bug to be fixed. Please, please report bugs in your distro to your distro's bug tracker. There's no guarantee that your issue will ever be fixed but your odds are vastly improved...
Xorg isn't licenced under GPL, it's mostly BSD / MIT (apart from things like fonts). Since Xgl is part of Xorg it too is under an MIT style licence. Being GPL would make things like binary drivers legally very dubious.
I've been using it for weeks. It has noticible bugs. Compiz (the compositing manager that lets you actually do a lot of the cool stuff) has bugs / lacks some of the good behavior of other window managers. Without the right extensions in your drivers it can be much slower in mundane operations than Xorg (e.g. video on cards/drivers without shader support). It's missing features (resizing the screen for games). It's exposed (new) nvidia driver bugs that take down X. Pressing shift-backspace kills the server (and any work that was on it). Not all 3D cards/drivers like it.
If you aren't the sort who knows (or wants to learn) how to file useful bug reports (with accurate information - i.e. "it's broken" doesn't cut it) and / or fix the code yourself I wouldn't try it for anything more than a few minutes.
It's probably your drivers to blame because I've heard similar reports from other ATI laptop users. Alas the closed ATI drivers seem to have a reputation for instablility and it can't be the cards fault because I'm told they are extremly stable under Windows/OS X. 'Tis a shame, but I guess there's not much of a business case to pour a ton of money into fixing 99% of the problems because the Linux 3D market is tiny.
Tough call. I'm going to say no for Voodoo's older than V3 due to the lack of DRI. For Voodoos V3-5 I'm going to say maybe not due to unimplemented features in the 3dfx driver. I'm basing this on information from the AIGLX project which is similar but different to Xgl so this could be wide of the mark.
However last I heard Xgl was trying to target OpenGL 1.3 (or 1.2 with a particular extension). If your driver doesn't implement those features you could be out of luck...
*Rolls eyes*
Your graphics driver doesn't yet support the GLX_EXT_texture_from_pixmap extension so every time that call is made (near enough any time the window changes) it is going to be emulated in software. As you do that opaque resize just think how many times it might be being called... Don't worry though - your 3D chipset vendor says they will implement it in their next driver release.
However at the end of the day what is acceptable to me could well not be acceptable to you - just two months ago everyone was complaining window dragging was too slow whereas I thought it was acceptable. On Xgl it seems quite fast to me but now we're on to the next of the never ending issues. I guess since you want something finished yesterday you had better start saving for / using that Mac...
I'm rather doubtful that platform matters when doing Google searches. Are you aware that Google has several different data centres around the world that do not always return exactly the same results? Also Google *does* show different results depending on whether you are using a localised Google or not, what preferences you have set (e.g. only return English pages) or whether you are using a themed Google (e.g. Google Linux).
You never know though. Do you have any solid repeatable data (e.g. using proxies and ensuring your searches are going to the same data centre) to prove that the platform does affect results?
I haven't been able to check the veracity of this but one of the comments hints at what Doug went on to do and why (the anchor link seems broken in Firefox, it's the comment that starts "Wow, except for the two obviously disgruntled stock market guys" by Frank Gilroy)...
There's no need to guess when you can check. A quick gander at wikipedia or google define says that an E1 offers 2.048 Mbit/s of bandwidth whereas a T1 offers 1.544 Mbit/s. However your cost point is taken since an E1 obviously isn't 50 times the speed T1...
If memory serves, most of these home routers are running on MIPS based hardware. There is no port of OpenBSD to the sbmips platform (yes there is an SGI MIPS port but I doubt it is similar enough for an easy transition). I believe NetBSD has been ported to this platform but I am unsure of whether the supported chipset is the same as that in a home router. There's also the possiblity that there won't be wifi card or ethernet drivers on NetBSD so you would have to reverse engineer those... Personally I'd just stick with Linux but porting a *BSD for full support would be an interesting exercise.
As another poster said, if you want to run OpenBSD on embedded hardware you are better off going for the soekris stuff but you'll pay a LOT more (prices for just the board without case, wifi card or power cable start at $128) than for the shelf consumer stuff (Amazon has a WRT54 for $54.99).
If you check the beginning ofthe 2.6.14 changelog you will find mention of a "ieee80211 subsystem" being merged. So hopefully all drivers will be ported to the generic in kernel 802.11 stack. This will hopefully take over WPA crypto duties from drivers. This also goes hand in hand with version 28 of Wireless Tools which will provide a basic (but standard) interface for WPA.
Yes the *BSDs are further down this track as pointed out in another comment buy it's nice to see Linux catching up and I believe HostAP and the Centrino drivers have already been converted over to using the generic 802.11 stack.