Agreed. A central desktop distro to rally around would be useful (perhaps unlikely, but useful).
Even more useful, though, in my opinion, would be a consistent package management system across distros. That way, we could choose a distro for a specialized-use case (e.g., servers, embedded systems, etc.) based on what packages it focuses its attention on and what its performance priorities are rather than based on which package management system it uses. Plus, bouncing back and forth between numerous different distributions -- one for each niche -- wouldn't be such a headache. (Now... which command was it that I use to update that package on this distro again? Argh.)
I was thinking something similar... some of us really *do* like all the lights. Of course, you could argue that those lights are "useful," whereas the lights that the article complains about are the "useless" ones. The flip side is that you could argue the "useless" lights wouldn't be there if *somebody* didn't like them... flash sells, what can I say?
The policy editor combined with a limited-privilege account (or, better, individual accounts) is definitely the place to start. Basically the policy editor just sets a bunch of registry keys that limit what can gui features are enabled. A better content filter is also worth your while.
PS: You can use a registry key to disable the task manager, also, without having to remap the Ctrl key (which remains useful for harmless things like cut/copy/paste/etc). ISTR that the policy editor doesn't actually have a built-in way to disable task manager, but the regkey does exist and you can set it manually.
Yes, as long as the analysis provides real, useful information.
I've seen cases before where security companies have discovered big piles of "vulnerabilities" in certain other high-profile open source products. The problem in those cases that made the "vulnerabilities" not entirely welcome "discoveries" was that really the security company had just run their automated code analysis product over the OSS codebase and dumped the results on the OSS community without looking over them first to weed out the sometimes large numbers of false positives. The security companies in those instances, presumably, were more interested in promoting their own security product ("look at all these vulnerabilities our product found!") than in truly enhancing the OSS product being examined.
At the K-12 school where I work, our upper school campus (grades 7-12) recently purchased a "mobile lab" -- a cart with enough notebook computers on it for a class to use, one notebook per kid.
Yes, we have sufficient web filtering and other blocks in place, so the kids can't waste time playing games or instant messenging. Yes, there is sufficient security on the computers to prevent the kids from installing a bunch of junk or otherwise modifying the settings of the computers. Yes, the school has 100% wireless coverage to service the mobile lab, but personally-owned computers are not allowed to connect to our network (wired *or* wireless).
Why am I posting this? Several comments responding to this article have stated things like, "That's what the COMPUTER LAB is for". But here's why that doesn't hold: yes, we have a traditional computer lab with a bunch of desktops in it. But we only have ONE traditional lab, and it's constantly overbooked. Many more teachers want to use it for their classes than there are time slots in the day available for them. So we have to turn classes away. As in many schools, space here is at an absolute premium... we don't have any "extra rooms" sitting around just waiting for me to load another twenty desktops into it. So the ONLY way for us to expand our lab facilities was to use the CLASSROOMS as labs... which means notebooks (and a cart). Sure desktops would have been a bit cheaper, but there was no place to PUT them.
I was initially concerned about excessive wear and tear on notebooks and the breakage that might ensue. But I was reassured by a number of my peers at other schools around the country that the mobile labs they've set up get a lot less broken than they anticipated, and furthermore, accidental damage insurance on the notebooks covers us just in case a screen gets broken or something else catastrophic occurs to one of the notebooks.
I guess it never occurred to the movie industry that perhaps sales/attendance are slumping because all of the movies they're coming out with these days are (a) expensive and (b) exactly the same as all the other movies for the last N years? "This story line worked before, it'll work again!"
In my humble opinion, FM radio sounds substantially better than the digital satellite radio I've heard. The compression artifacts in the digital radio with that low a bit rate are VERY apparent to any kind of moderately discerning listener. One particularly annoying problem is that the highs (e.g., cymbals) get to sounding really "crunchy". To me, it's the radio equivalent of having somebody run their fingers down the chalkboard. It's that bad. At least with FM radio (that's properly modulated) the worst of the problems is a propensity for excessive bassiness. I can live with that a lot more readily than I can distorted highs.
Why I could possibly want to both pay for the satellite service AND record it for posterity is beyond me. I'd rather just buy the CD and have it sound the way it was intended.
An extension of this could mean that any documents you create under a future version of MS Office could potentially be copyrighted by MS.
Though IANAL, I suspect this is incorrect: you can't implicitly assign copyright. It has to be done by a specific kind of document that very explicitly lists the particular copyrighted items being transferred and so forth. Refer to various Novell court filings in SCO v. Novell for details.
Of course it does... it couldn't bind to port 80 if it didn't start up as root. You are correct that it is the children that run with decreased privileges.
If somebody has gotten enough access to your box to add an arbitrary module to your httpd config, you're in pretty big trouble anyhow...
As for organizations beating slashdot to the punch on this one, that's true... but it's good to see this getting even more exposure.:)
GPGPU (General-Purpose computation on GPUs) was a hot topic at various conferences in 2003; a number of papers were published on the subject. At SIGGRAPH 2004 there will be a full-day course on GPGPU given by eight of the experts in the field (including myself).
Mark Harris of NVIDIA maintains a website dedicated to GPGPU topics, including discussion forums and news postings. Well worth a browse if you're interested in GPGPU topics.
I look forward to seeing some of you at SIGGRAPH!:)
Like I said in another comment, 1.3.25 and 2.0.39 have been tagged in CVS and will be released in the morning (US eastern time). You can go ahead and grab the new versions from CVS if you're in a hurry.
the prefork MPM is the default on Unix in general. We talked about switching the worker MPM (the hybrid threads/processes one) to be the default, but didn't do it for some reason or another. That's not to say that you shouldn't use the worker MPM... if your platform has good threading support, then by all means, worker is the way to go. It scales far, far better than prefork. However, it's true that you can't run a threaded Apache (and therefore the worker MPM) on FreeBSD right now. We're working on that, but it's still unclear exactly where the problem is.
the prefork MPM is not listed as experimental. If it is, it's a mistake (tell me where it says that and I'll change it!). The only one that's listed as experimental is perchild, which is the one that lets you configure the server to run certain virtual hosts under certain child processes and to assign different uid's to each child process.
If you can wait just a little while, Ryan Bloom, one of the Apache developers, has written a book called Apache Server 2.0: The Complete Reference. It's due out at the end of May.
Here's the Amazon link.
I wrote that article.:) [As I mentioned in another comment on this/. story, the article is now posted online, btw.] At the time I wrote the article, it's true that Apache 2.0 wasn't performing as well as 1.3. But I wrote it in like October. In the months since then, especially within just the last month since we added the bucket brigade freelists to avoid all the bazillion malloc/free calls and since much other performance tuning has been done by various members of the development team, 2.0 has started to really kick 1.3's butt. Have a look at this post to dev@apr.apache.org from Brian Pane on April 1, where he posted some side-by-side performance comparison numbers.
Re:Error when building on Solaris 8
on
Apache 2.0 Goes Gold!
·
· Score: 2, Informative
There might be a patch you need, because I know for a fact that several developers reported 2.0.35 testing out fine on their Solaris 8 boxes before we released it. I've forwarded your comment to dev@httpd.apache.org and will let you know if anybody comes back with an answer to this problem.
Re:Where do they recommend to use 2.0 over 1.3.24?
on
Apache 2.0 Goes Gold!
·
· Score: 1
That was my fault. I forgot to remove that paragraph from httpd.apache.org yesterday when I was madly scrambling to update the site. You'll notice today that it's gone.:) 2.0.35 *is* the best version of Apache available, and we strongly urge you to upgrade from 1.3 as soon as all of the modules you need have been ported forward.
[You'd be amazed at how many copies of things there are to update on the apache.org websites when putting out a release.:]
Slashdot Mirror
...if you are installing the cables in a plenum. http://en.wikipedia.org/wiki/HVAC#Plenum_space http://en.wikipedia.org/wiki/Plenum_cable
Agreed. A central desktop distro to rally around would be useful (perhaps unlikely, but useful).
Even more useful, though, in my opinion, would be a consistent package management system across distros. That way, we could choose a distro for a specialized-use case (e.g., servers, embedded systems, etc.) based on what packages it focuses its attention on and what its performance priorities are rather than based on which package management system it uses. Plus, bouncing back and forth between numerous different distributions -- one for each niche -- wouldn't be such a headache. (Now... which command was it that I use to update that package on this distro again? Argh.)
I was thinking something similar... some of us really *do* like all the lights. Of course, you could argue that those lights are "useful," whereas the lights that the article complains about are the "useless" ones. The flip side is that you could argue the "useless" lights wouldn't be there if *somebody* didn't like them... flash sells, what can I say?
The policy editor combined with a limited-privilege account (or, better, individual accounts) is definitely the place to start. Basically the policy editor just sets a bunch of registry keys that limit what can gui features are enabled. A better content filter is also worth your while.
PS: You can use a registry key to disable the task manager, also, without having to remap the Ctrl key (which remains useful for harmless things like cut/copy/paste/etc). ISTR that the policy editor doesn't actually have a built-in way to disable task manager, but the regkey does exist and you can set it manually.
Yes, as long as the analysis provides real, useful information.
I've seen cases before where security companies have discovered big piles of "vulnerabilities" in certain other high-profile open source products. The problem in those cases that made the "vulnerabilities" not entirely welcome "discoveries" was that really the security company had just run their automated code analysis product over the OSS codebase and dumped the results on the OSS community without looking over them first to weed out the sometimes large numbers of false positives. The security companies in those instances, presumably, were more interested in promoting their own security product ("look at all these vulnerabilities our product found!") than in truly enhancing the OSS product being examined.
At the K-12 school where I work, our upper school campus (grades 7-12) recently purchased a "mobile lab" -- a cart with enough notebook computers on it for a class to use, one notebook per kid.
Yes, we have sufficient web filtering and other blocks in place, so the kids can't waste time playing games or instant messenging. Yes, there is sufficient security on the computers to prevent the kids from installing a bunch of junk or otherwise modifying the settings of the computers. Yes, the school has 100% wireless coverage to service the mobile lab, but personally-owned computers are not allowed to connect to our network (wired *or* wireless).
Why am I posting this? Several comments responding to this article have stated things like, "That's what the COMPUTER LAB is for". But here's why that doesn't hold: yes, we have a traditional computer lab with a bunch of desktops in it. But we only have ONE traditional lab, and it's constantly overbooked. Many more teachers want to use it for their classes than there are time slots in the day available for them. So we have to turn classes away. As in many schools, space here is at an absolute premium... we don't have any "extra rooms" sitting around just waiting for me to load another twenty desktops into it. So the ONLY way for us to expand our lab facilities was to use the CLASSROOMS as labs... which means notebooks (and a cart). Sure desktops would have been a bit cheaper, but there was no place to PUT them.
I was initially concerned about excessive wear and tear on notebooks and the breakage that might ensue. But I was reassured by a number of my peers at other schools around the country that the mobile labs they've set up get a lot less broken than they anticipated, and furthermore, accidental damage insurance on the notebooks covers us just in case a screen gets broken or something else catastrophic occurs to one of the notebooks.
Shrug.
I guess it never occurred to the movie industry that perhaps sales/attendance are slumping because all of the movies they're coming out with these days are (a) expensive and (b) exactly the same as all the other movies for the last N years? "This story line worked before, it'll work again!"
:-P
Thanks, guys.
In my humble opinion, FM radio sounds substantially better than the digital satellite radio I've heard. The compression artifacts in the digital radio with that low a bit rate are VERY apparent to any kind of moderately discerning listener. One particularly annoying problem is that the highs (e.g., cymbals) get to sounding really "crunchy". To me, it's the radio equivalent of having somebody run their fingers down the chalkboard. It's that bad. At least with FM radio (that's properly modulated) the worst of the problems is a propensity for excessive bassiness. I can live with that a lot more readily than I can distorted highs.
Why I could possibly want to both pay for the satellite service AND record it for posterity is beyond me. I'd rather just buy the CD and have it sound the way it was intended.
Though IANAL, I suspect this is incorrect: you can't implicitly assign copyright. It has to be done by a specific kind of document that very explicitly lists the particular copyrighted items being transferred and so forth. Refer to various Novell court filings in SCO v. Novell for details.
Of course it does... it couldn't bind to port 80 if it didn't start up as root. You are correct that it is the children that run with decreased privileges.
If somebody has gotten enough access to your box to add an arbitrary module to your httpd config, you're in pretty big trouble anyhow...
As for organizations beating slashdot to the punch on this one, that's true... but it's good to see this getting even more exposure. :)
GPGPU (General-Purpose computation on GPUs) was a hot topic at various conferences in 2003; a number of papers were published on the subject. At SIGGRAPH 2004 there will be a full-day course on GPGPU given by eight of the experts in the field (including myself).
Mark Harris of NVIDIA maintains a website dedicated to GPGPU topics, including discussion forums and news postings. Well worth a browse if you're interested in GPGPU topics.
I look forward to seeing some of you at SIGGRAPH! :)
--Cliff
Definitely upgrade. Note also that full details of the problem will be released on Friday.
--Cliff Woolley
Apache HTTP Server Project
Apache 2.0.46 Release Management team
Not just a DoS anymore, an exploit for 32-bit platforms has been released. Please see http://httpd.apache.org/.
Not any more. A remote exploit for OpenBSD has been released on bugtraq. You're very vulnerable.
Can you be more specific? Which installer (2.0.39 or 1.3.26)? What exactly happens?
Like I said in another comment, 1.3.25 and 2.0.39 have been tagged in CVS and will be released in the morning (US eastern time). You can go ahead and grab the new versions from CVS if you're in a hurry.
OKAY, HERE'S THE OFFICIAL WORD FOR THE NIGHT:
1.3.25 and 2.0.39 have been tagged in CVS. Both versions have the vulnerability fixed. They will be released first thing in the morning.
YOU SHOULD UPGRADE. Don't think that this is a small problem; you'd be mistaken.
The fact that it doesn't describe the entire scope of the problem. See the official announcement on httpd.apache.org to understand why.
Updated releases of both 1.3 and 2.0 that fix this problem will be released VERY shortly.
the prefork MPM is the default on Unix in general. We talked about switching the worker MPM (the hybrid threads/processes one) to be the default, but didn't do it for some reason or another. That's not to say that you shouldn't use the worker MPM... if your platform has good threading support, then by all means, worker is the way to go. It scales far, far better than prefork. However, it's true that you can't run a threaded Apache (and therefore the worker MPM) on FreeBSD right now. We're working on that, but it's still unclear exactly where the problem is.
the prefork MPM is not listed as experimental. If it is, it's a mistake (tell me where it says that and I'll change it!). The only one that's listed as experimental is perchild, which is the one that lets you configure the server to run certain virtual hosts under certain child processes and to assign different uid's to each child process.
If you can wait just a little while, Ryan Bloom, one of the Apache developers, has written a book called Apache Server 2.0: The Complete Reference. It's due out at the end of May. Here's the Amazon link.
I wrote that article. :) [As I mentioned in another comment on this /. story, the article is now posted online, btw.] At the time I wrote the article, it's true that Apache 2.0 wasn't performing as well as 1.3. But I wrote it in like October. In the months since then, especially within just the last month since we added the bucket brigade freelists to avoid all the bazillion malloc/free calls and since much other performance tuning has been done by various members of the development team, 2.0 has started to really kick 1.3's butt. Have a look at this post to dev@apr.apache.org from Brian Pane on April 1, where he posted some side-by-side performance comparison numbers.
There might be a patch you need, because I know for a fact that several developers reported 2.0.35 testing out fine on their Solaris 8 boxes before we released it. I've forwarded your comment to dev@httpd.apache.org and will let you know if anybody comes back with an answer to this problem.
[You'd be amazed at how many copies of things there are to update on the apache.org websites when putting out a release. :]