You're probably better informed than I am. But just as you said, this would be a really dumb move by apple. I hope they're not shooting themselves into the foot like that...
If older chipsets are not supported at all then I guess the mini will soon be upgraded to a new gfx board. I just can't imagine that apple intends to sell hardware that cripples the OS in such a (literally) visible way. Talk about bad press...
And yes, spotlight looks promising. I'm curious whether it proves to be as useful as it could be.
people have been reluctant to impose many megabytes of extra memory footprint merely to give users quick iconic previews of window contents.
Sad. When it's possible it should be an option (on/off switch in the user-preferences).
Not that I'm a big expose-fan but I've heard some people like it.
I, personally, would be more interested in window-zoom that could be implemented using the same mechanism. I imagine a feat. that zooms a window to it's original size when it gets mouse-focus and smoothly shrinks it by 50% (or whatever the user desires) when it loses focus.
That way I could easily arrange my dozen or so windows on the desktop (they'd be only about windowmaker-icon-size) and always see at a glance what's there.
That would be so much better (and more intuitive) than all the iconify and roll-up kludges we've come up with over the years...
From what I've read (and we're both speculating here!) CI will degrade gracefully on older hardware. So you might not get *all* the eyecandy but most of it.
Generally you should always buy a system that fulfills your needs *right now* because you can never be sure that future innovations will be fully backported.
I got my iBook around the same time (G4 1.2GHZ) and it does everything I need. Unless apple puts a killer-feature in tiger I see no need to even consider paying money for that.
Only judging by how far ahead apple is *right now* I'd dare to doubt this is gonna change with longhorn.
It was a very smart move by apple to move their OS to the stable darwin (BSD-like) core. Now they're building on a stable and proven foundation (developement speed has likely increased) where MS still fiddles their legacy mess with no way out.
We all know how buggy MS software is and if longhorn turns out like any of their previous OS releases they might have a harder time forcing their userbase into yet another paid Beta-test than the last times. After all the kids growing up today are more computer-savvy than ever and and not that easy to fool anymore. Even more so with the alternatives (OS X, maybe even linux in a few years) getting better and better.
Comparing the polished OS X desktop (springloaded-folders, responsiveness, integration, drag'n'drop software install/uninstall, eyecandy) to the windows crapshow (bugs, bugs, bugs, crashes, security holes, registry mess, spyware) is almost not fair anymore.
Sorry I was probably unclear. Ofcourse I didn't expect to get the data back but LVM should be able to deal with a disc failure so you can swap in a good disk and reconstruct the volume(s). That's the part that didnt work for me. LVM spit some strange error messages and refused to accept a new disk. I would probably have been able to create a new volume after manually carving the data from the old one (which couldnt be mounted anymore...) but after that procedure I didn't feel like using it again. Except when LVM2 was out for a while I gave that one another shot but on the first disk failure it behaved the same strange way (with other error messages). I have now moved back to just "a bunch of disks" for my non-important stuff (the important stuff is on raid) so at least when one fails the others are not affected. Having it all appear as one big disk was a convinient but definately not worth the trouble I had in the end.
I have had some trouble with linux LVM (both 1 and 2) and would suggest to perform heavy testing before trusting it on a production system. The two LVM setups I had both broke down in exactly the moment when there were needed - when a disk failed. I had no success in reviving the volumes with a new disk (or without) and even though most of the data could be recovered with some heavylifting (no big surprise - the other disks were fine after all) it would've been a nightmare in a production env. I'm still not sure what exactly went wrong but the normal recovery procedure didn't work and the LVM tools act *very* flakey when anything goes wrong.
I have no expirience with XFS but the freeze feature sounds interesting.
Thanks for the pointer, dar is really awesome. I knew bacula before but never got around to actually test it. It seems a bit bloated to me and while many features it has are nice it lacks the smartness of dar.
Don't do this. You want to buy a (fairly affordable) serial terminal server (1 ethernet to n serial ports). The TS is the single point of failure (they're built to avoid failing...) then but the setup you described is far worse.
In case of emergency you want to get to the affected host *real quick*. You do not want to waste time wondering why the serial link is not responding (some getty choking on the other hosts serial console messages?) or why two or more machines are not responding via serial while only one was reported to be down. When the worst case happens (ethernet goes down) and you depend on the serial link to get around these are the last things you want to deal with.
I've worked a bit with serial access and believe me, many funny things can happen. I've seen a rebooting host take the one it was wired to down. Boot messages from "B" triggered the login prompt on "A". When "B" was done booting it had its own login triggered by the login prompt from "A" (loop...). I have seen serial ports randomly lock up or stop working (sometimes recoverable via reset, sometimes they just went south and never came back). I have seen BIOS'es forgetting the port speed / handshake settings causing all kinds of trouble. I even had a host that would one day, for no apparent reason (there was not even a getty running) put a stream of random garbage on the serial port and nothing helped to stop it (port reset on TS, setting stop bit etc).
When your boxes are connected to a TS then whatever wierdness they may come up with will hit the terminal server which can usually deal with it (or in worst case you lose the TS for a while). When they're connected to each other... well, you get the idea.
Games will likely move on to subscription services (steam shows the way). The next level of escalation comes with people breaking the network uplink of those games (either by hacking the game or inserting a proxy) so at least standalone play works (online play won't). The vendors will in turn add strong crypto and then the battle begins to blend in with the rest of the whole DRM mess we're looking forward to.
Despite the tone of my previous post (there haven't been any successful copy protection mechanisms in the past) it might very well be possible to implement them - in a networked world.
I have very mixed feelings about that kind of control in the hands of large corporations (EA) where large parts of the target audience consists of children and teenagers.
Will the content delivered along with the DRM client stay sober, as in, will they just keep on cooking the kids brains with advertising (steam) or will more dangerous messages begin to trickle in the gaming worlds (cf. "americas army")?
Trust me, it would have been the same if the game would've had protection. Can anyone name a single game where the pirates failed to break the protection? That's right, there is none.
Most new copy protection schemes were broken within days in the past.
Well, I hope you're right with your more optimistic view. It wouldn't be the first time for MS to fail so maybe there's really a chance this all turns out as vapor in the long run.
What about emulators which might be able to emulate the TC chip? Such emulators could theoretically provide a massive hole in the system and would either be deemed illegal under the DMCA as a circumvention device or would allow us to actually run, saw Windows and IE on VMWare in a pretend-trusted environment.
Well, by my understanding of the TCPA FAQ this would be a pretty tough job as they are using strong crypto this time. It might be possible to emulate a chip that does "nothing" but fake their API (always returning "OK") to trick applications into believing they are inside their jail. But that would likely only work for a limited time until they "improve" it even more. I do believe it could be technically possible to make this airtight to a point where it's not making sense anymore to try and reverse engineer it. If we get to that point we'd have a whole new kind of "digital divide" (ppl locked in to the MS-world vs the rest).
On the other hand I still have quite a bit of faith in Microsoft's track-record of fucking anything up that has to do with software.;-) Wouldn't be surprised if they simply fail on the technical challenge...
But I don't see consumers deciding that this is necessary in the reasonable term.
The consumers are not deciding anything on that matter. TC is being implemented in hardware right now and if that goes on at the current pace you will, in a few years. have a hard time buying a new PC without builtin TC chip.
The consumers will be conditioned to use it by the usual FUD strategies. "Secure" onlineshopping/onlinebanking will suddenly no longer mean "SSL required" but "TC crypto required". Internet Explorer will threaten the user with appropiate warning messages ("Oh, this website is only using SSL, you really should look for a more secure shopping site") and, just as today, it will all seem normal to the uneducated user. The masses will follow because they don't know any better.
We can all only hope that these efforts fail miserably or I foresee a big stinkin' mess 10yrs down the road...
Hopefully enough people and the mainstream media realize in time what they are attempting to do but I fear Microsoft's money will silence too many otherwise critical journalists.
You're making a very broad statement there. Just because a company is large it doesn't mean they don't take pride and responsibility in their code. I know a lot of people personally who work at MS, Google, Apple, Motorola etc who all take pride in what they do and work hard to do the best damn job they can. Just because it's not open source, doesn't mean it is bad, and I am guessing there are a lot of programmers working hard at fixing the bugs and security issues in both IE and Mozilla.
I'm making that broad statement by my past expirience with the (lack of) quality in MS products, their own public relation (press releases, advertising, FUD) and what I've read in a number of articles by different ex-MS employees. By all that I know about their corporate culture and developement process from these sources I'm in no way surprised that the outcome is what it is. I could be all mistaken (no first-hand expirience) but the pieces match up pretty well...
I checked both links...both programs have about 1/3 of their bugs left unpatched. Yes, IE has more bugs, that's no secret. There are more linux fanboy hackers out there trying to destroy MS, also a fact. I expect more bugs in a more widely used program with a known contingency of "enemies". The interesting thing to me is that both programs have 1/3 of the vulnerabilities unptched. While you're at it, take a look at the Firefox one as well. FireFox Nice job Firefox 1.X, only on the market for a few months and already 4/5 security flaws are unfixed? Cleary this is not an appropriate measure.
See, I knew something like this would come out. That's why I told you to look beyond the pretty pie charts and actually read the bug descriptions. If you had done that you'd know that most bugs listed for Mozilla are spoofing vulnerabilities (display a wrong URL in status-bar and such) while most bugs listed for IE are actual remote code execution vulnerabilities.
Seriously though, SP2 is a security improvement for the people previously running with no firewall. I don't think you can logically argue against that. Those of us behind a firewall already, also running antivirus are probably not in any better situation, I agree.
Yes, I can logically argue against that. The "security improvement" is a bunch of long overdue bugfixes (some of which broke other things) and a half-baked implementation of a desktop firewall that, among other problem, even kicks in too late (machines were reported to be infected during OS-install).
Wake me up when MS stops the patchworking and actually overhauls their developement process in order to stop at least the most humiliating bugs from happening. Tools and frameworks to automatically avoid whole classes of buffer overflows have been available for quite a while. I can only guess why MS isn't implementing these and my guess would be that they tried but stepped back from it because the tools have likely marked whole components as "throw away and try again". The other option (just as likely) would be that they have never tried and just don't care.
So the people who write the code for both places deserve no respect for the work they do?
That's the exact problem. I highly doubt that anyone at MS feels personally responsible for the IE mess. The emberassment would hardly be bearable for a single person anyways...
Yeah, there are bugs in both programs, and yes both of them have serious bugs at times.
At times? Let me think, the number of critical IE bugs certainly goes in the mid 2-digit range (maybe they've even hit 3 digits already?). How many remotely exploitable Mozilla bugs have there been? I don't remember a single one so if there were any it must have been few. Now compare the developement models of the two. IE is backed up by a multi-billion dollar company that could very well afford proper Q/A... need I say more?
both IE and Firefox have been doing ok lately at getting patches for them
Gimme a break. Compare this to this. And be sure to look past the pretty pie charts for the actual vulnerability descriptions.
it seems like we could be a bit more fair around here and at least either treat both browsers as if they suck, or treat them both with respect.
I'm touched by your call for humanity. But they're friggin browsers. That's software, not people, mmkay?
The reason why people treat IE and Mozilla so differently is because IE does indeed suck bad and Mozilla does indeed suck far less. People are stunned that a multi-billion dollar company constantly refuses to apply proper QA to their software but instead sells expensive packages that are so bug-ridden that many real developers would be ashamed to only call it a "beta".
Back on topic: These three "bugs" in the story (two of which have been fixed long ago, before v1.0) are pretty ridiculous compared to what MS comes up with every couple weeks. None of these Moz-bugs would allow a remote attacker to execute code on your box. Most remote IE-exploits that I have seen allow an attacker to do just that.
Therefor, the IE codebase (and the company responsible for it) deserve no respect whatsoever.
Well, despite you're just a flaming AC I'll take the time and respond...
"1. You choose and know what will be running, including all libraries (starting from glibc), patches, compiler and interpreter versions"
That seems good, provided you are a real expert on all those fields. I bet you aren't, so you are doomed to make bad choices here.
Guess what, it's my job and I'm getting paid to be an expert on "all those fields" (which really is just advanced unix knowledge).
"2. When something breaks you know where to look because you set it up."
Probably a good reason. But then again, only *you* know that. If I were your boss this thing only is enough for me to fire you. I can and even want to have critical people because of his technical knowledge on the field and his work ability, but I don't want someone to be critical because of his knowledge of my company innerhoods, the one persons that works in a way that makes him unfireable is fired as soon as this is discovered so he doesn't have time to make things worse.
Ever heard about documentation? If you don't trust your staff that's a different story and you probably have bigger problems then.
"3. When working with pkg managers it can be hard to repeat an exact installation of what you blessed to be your stable environment."
That's bullshit. And it is such a bullshit that it can only mean that you have no idea about what a package manager is for, how does it works and which choices do you have. Then, all what you say about deploying you own LFS-like boxes is tainted from your unknowledgeability, and then not to be taken seriously. What package manages are FOR is (among other things) to achieve repeatability. I can (and do) deploy "clonic" boxes out from CVS (for config files) and package manager lists (either form rpm and/or dpkg) with total asurance of the results. You can't, OK, that's your problem, don't blame the tools you don't know about.
Dude, I've been working with kickstart (RedHat) and FAI (debian) for over a year. If you had that expirience you'd probably know that after a while you come to the point where you have to divert from the distro branch just because you don't want to update that friggin glibc just yet and everything else starts to depend on the updated package. So you end up with a custom repository and start backporting packages where it matters. RedHat is already lost at that point (maybe they're better nowadays but back then RPM-hell made me abandon it). Debian/stable is indeed quite stable but when your (considerably complex) FAI framework breaks down the nth time because some of the scripting magic is not as robust as it should be you begin to realize that rolling your own tarball is just so much less pita.
"you can hardly rely on apt-get or rpm to still provide the exact set of software that you once had (without updates getting in the way that depend on other updates etc.)"
Don't talk about what you ignore. I bet you *never* have properly used Debian under a production environment, otherwise you wouldn't say that. I *do* work with RH, and I *do* work with Debian, and I can tell you that having an upgrade that breaks your system is neither rpm's nor dpkg's fault, but their respective's distribution policy. I had Red Hat shoot me in the face some four o five times in the past due to a faulty upgrade (not that the package upgrade failed but because the new version broke something else), because Red Hat envisions their systems in a certain way. That's to me a big NO-NO, so I neither install nor counsel people to do so except when extrictly needed (and I try to do all on my hand to avoid those situations); now, Debian's policy is quite different and as a result, I didn't have a faulty upgrade on Stable boxes for almost six years (it is not that I had it six years ago, but that I have used Debian only from six years ago).
Since none of the commercial middleware and relational database vendors support anything except the commercial "enterprise" distributions, running stock kernels and stock everything else, you're pretty much blowing hot air here. Unless you think that the multi-cpu Oracle systems running on RHEL and SLES aren't "real" servers, which would be a pretty interesting position to take.
These are not servers within your responsibility. You buy them as blackboxes and expect oracle-support to keep them running for you. More an "appliance" than a server to me and why not, as long as oracle pays for downtime.
I'll try to explain further, this is why it is essential:
1. You choose and know what will be running, including all libraries (starting
from glibc), patches, compiler and interpreter versions. No generic distro
package will be optimized for your purpose because no maintainer knows what
set of services is critical to you and what configuration options are
appropiate. You do not want to run public services with all kinds of
unnecessary modules and options compiled it (many of which could become
a security problem in the future).
2. When something breaks you know where to look because you set it up.
When the quarterly openssl hole is announced you get the patch and deploy
the new version without having to wait for a distro package to come out
and without having to audit the distro package (is it properly fixed, does
it break other stuff, does it depend on newest glibc that will upgrade half
your system to an unknown state?).
3. When working with pkg managers it can be hard to repeat an exact
installation of what you blessed to be your stable environment.
If you need to replicate a server you end up tar'ring it up anyways
because you can hardly rely on apt-get or rpm to still provide the exact
set of software that you once had (without updates getting in the way that
depend on other updates etc.)
So why not start from a well-defined base tarball in first place...
4. By diverting from the large population of default installations you evade
generic "mass"-exploits (worms).
5. Last but not least:
You do not want automatic updates on a server, period.
You setup and test the thing once, then it is a Running System.
There is no reason to "stay in sync" with anyone, as long as
your system ticks you would be a moron to change anything.
There are exactly two reasons to update a piece of software
on a live-system:
a) security problem (usually patch + recompile of the affected pkg)
b) you need an addtl service that depends on a newer version of something
Don't get me wrong, distros are fine for newbies, desktops, small/non-exposed servers and the like. For anything serious I wouldn't trust my business to someone who deploys distro updates (with depends) to a running prod. server.
Slashdot Mirror
Why can't we do what we love for companies that appreciate our work and who are as loyal to us as we are to them?
Where do I sign?
You're probably better informed than I am.
But just as you said, this would be a really dumb move by apple.
I hope they're not shooting themselves into the foot like that...
If older chipsets are not supported at all then I guess the mini will soon be upgraded to a new gfx board. I just can't imagine that apple intends to sell hardware that cripples the OS in such a (literally) visible way. Talk about bad press...
And yes, spotlight looks promising. I'm curious whether it proves to be as useful as it could be.
people have been reluctant to impose many megabytes of extra memory footprint merely to give users quick iconic previews of window contents.
Sad. When it's possible it should be an option (on/off switch in the user-preferences).
Not that I'm a big expose-fan but I've heard some people like it.
I, personally, would be more interested in window-zoom that could be implemented using the same mechanism. I imagine a feat. that zooms a window to it's original size when it gets mouse-focus and smoothly shrinks it by 50% (or whatever the user desires) when it loses focus.
That way I could easily arrange my dozen or so windows on the desktop (they'd be only about windowmaker-icon-size) and always see at a glance what's there.
That would be so much better (and more intuitive) than all the iconify and roll-up kludges we've come up with over the years...
From what I've read (and we're both speculating here!) CI will degrade gracefully on older hardware. So you might not get *all* the eyecandy but most of it.
Generally you should always buy a system that fulfills your needs *right now* because you can never be sure that future innovations will be fully backported.
I got my iBook around the same time (G4 1.2GHZ) and it does everything I need.
Unless apple puts a killer-feature in tiger I see no need to even consider paying money for that.
Only judging by how far ahead apple is *right now* I'd dare to doubt this is gonna change with longhorn.
It was a very smart move by apple to move their OS to the stable darwin (BSD-like) core. Now they're building on a stable and proven foundation (developement speed has likely increased) where MS still fiddles their legacy mess with no way out.
We all know how buggy MS software is and if longhorn turns out like any of their previous OS releases they might have a harder time forcing their userbase into yet another paid Beta-test than the last times.
After all the kids growing up today are more computer-savvy than ever
and and not that easy to fool anymore. Even more so with the alternatives
(OS X, maybe even linux in a few years) getting better and better.
Comparing the polished OS X desktop (springloaded-folders, responsiveness, integration, drag'n'drop software install/uninstall, eyecandy) to the windows crapshow (bugs, bugs, bugs, crashes, security holes, registry mess, spyware) is almost not fair anymore.
Trained doves can carry attachments up to 100grams.
Sorry I was probably unclear.
Ofcourse I didn't expect to get the data back but LVM should be able to deal with a disc failure so you can swap in a good disk and reconstruct the volume(s).
That's the part that didnt work for me. LVM spit some strange error messages and refused to accept a new disk. I would probably have been able to create a new volume after manually carving the data from the old one (which couldnt be mounted anymore...) but after that procedure I didn't feel like using it again.
Except when LVM2 was out for a while I gave that one another shot but on the first disk failure it behaved the same strange way (with other error messages).
I have now moved back to just "a bunch of disks" for my non-important stuff (the important stuff is on raid) so at least when one fails the others are not affected. Having it all appear as one big disk was a convinient but definately not worth the trouble I had in the end.
I have had some trouble with linux LVM (both 1 and 2) and would suggest to perform heavy testing before trusting it on a production system.
The two LVM setups I had both broke down in exactly the moment when there were needed - when a disk failed. I had no success in reviving the volumes with a new disk (or without) and even though most of the data could be recovered with some heavylifting (no big surprise - the other disks were fine after all) it would've been a nightmare in a production env.
I'm still not sure what exactly went wrong but the normal recovery procedure didn't work and the LVM tools act *very* flakey when anything goes wrong.
I have no expirience with XFS but the freeze feature sounds interesting.
Thanks for the pointer, dar is really awesome.
I knew bacula before but never got around to actually test it.
It seems a bit bloated to me and while many features it has are nice it lacks the smartness of dar.
Full agree with parent.
/home/blah/bigfile /mnt/cdrom/bigfile).
When you backup to DVD or CD-ROM make sure to run a verify after every backup!
Verify means comparing the files that you meant to write to those that actually read back from the disc (diff
You'd be surprised how often many CD/DVD-writers screw up some files or even the whole disc. If you skip the verify you'll learn it the hard way.
Good luck when it goes down and your "schlepper" announces that "oops" the last backup tape smells funny.
Don't do this. You want to buy a (fairly affordable) serial terminal server (1 ethernet to n serial ports). The TS is the single point of failure (they're built to avoid failing...) then but the setup you described is far worse.
In case of emergency you want to get to the affected host *real quick*.
You do not want to waste time wondering why the serial link is not responding (some getty choking on the other hosts serial console messages?) or why two or more machines are not responding via serial while only one was reported to be down.
When the worst case happens (ethernet goes down) and you depend on the serial link to get around these are the last things you want to deal with.
I've worked a bit with serial access and believe me, many funny things can happen. I've seen a rebooting host take the one it was wired to down. Boot messages from "B" triggered the login prompt on "A". When "B" was done booting it had its own login triggered by the login prompt from "A" (loop...).
I have seen serial ports randomly lock up or stop working (sometimes recoverable via reset, sometimes they just went south and never came back).
I have seen BIOS'es forgetting the port speed / handshake settings causing all kinds of trouble. I even had a host that would one day, for no apparent reason (there was not even a getty running) put a stream of random garbage on the serial port and nothing helped to stop it (port reset on TS, setting stop bit etc).
When your boxes are connected to a TS then whatever wierdness they may come up with will hit the terminal server which can usually deal with it (or in worst case you lose the TS for a while).
When they're connected to each other... well, you get the idea.
You mean I can get a copy? How many gigs is that?
Would make a lovely testing playground for people developing or experimenting with spam filters...
Games will likely move on to subscription services (steam shows the way). The next level of escalation comes with people breaking the network uplink of those games (either by hacking the game or inserting a proxy) so at least standalone play works (online play won't). The vendors will in turn add strong crypto and then the battle begins to blend in with the rest of the whole DRM mess we're looking forward to.
Despite the tone of my previous post (there haven't been any successful copy protection mechanisms in the past) it might very well be possible to implement them - in a networked world.
I have very mixed feelings about that kind of control in the hands of large corporations (EA) where large parts of the target audience consists of children and teenagers.
Will the content delivered along with the DRM client stay sober, as in, will they just keep on cooking the kids brains with advertising (steam) or will more dangerous messages begin to trickle in the gaming worlds (cf. "americas army")?
Sorry, I got a bit taken away here...
But isn't that the kind of piracy that hurts the least?
At least one copy is bought that way.
Trust me, it would have been the same if the game would've had protection.
Can anyone name a single game where the pirates failed to break the protection?
That's right, there is none.
Most new copy protection schemes were broken within days in the past.
Well, I hope you're right with your more optimistic view.
;-)
It wouldn't be the first time for MS to fail so maybe there's really a chance this all turns out as vapor in the long run.
What about emulators which might be able to emulate the TC chip? Such emulators could theoretically provide a massive hole in the system and would either be deemed illegal under the DMCA as a circumvention device or would allow us to actually run, saw Windows and IE on VMWare in a pretend-trusted environment.
Well, by my understanding of the TCPA FAQ this would be a pretty tough job as they are using strong crypto this time.
It might be possible to emulate a chip that does "nothing" but fake their API (always returning "OK") to trick applications into believing they are inside their jail. But that would likely only work for a limited time until they "improve" it even more. I do believe it could be technically possible to make this airtight to a point where it's not making sense anymore to try and reverse engineer it. If we get to that point we'd have a whole new kind of "digital divide" (ppl locked in to the MS-world vs the rest).
On the other hand I still have quite a bit of faith in Microsoft's track-record of fucking anything up that has to do with software.
Wouldn't be surprised if they simply fail on the technical challenge...
But I don't see consumers deciding that this is necessary in the reasonable term.
The consumers are not deciding anything on that matter. TC is being implemented in hardware right now and if that goes on at the current pace you will, in a few years. have a hard time buying a new PC without builtin TC chip.
The consumers will be conditioned to use it by the usual FUD strategies.
"Secure" onlineshopping/onlinebanking will suddenly no longer mean "SSL required" but "TC crypto required". Internet Explorer will threaten the user with appropiate warning messages ("Oh, this website is only using SSL, you really should look for a more secure shopping site") and, just as today, it will all seem normal to the uneducated user. The masses will follow because they don't know any better.
We can all only hope that these efforts fail miserably or I foresee a big stinkin' mess 10yrs down the road...
Hopefully enough people and the mainstream media realize in time what they are attempting to do but I fear Microsoft's money will silence too many otherwise critical journalists.
You're making a very broad statement there. Just because a company is large it doesn't mean they don't take pride and responsibility in their code. I know a lot of people personally who work at MS, Google, Apple, Motorola etc who all take pride in what they do and work hard to do the best damn job they can. Just because it's not open source, doesn't mean it is bad, and I am guessing there are a lot of programmers working hard at fixing the bugs and security issues in both IE and Mozilla.
I'm making that broad statement by my past expirience with the (lack of) quality in MS products, their own public relation (press releases, advertising, FUD) and what I've read in a number of articles by different ex-MS employees. By all that I know about their corporate culture and developement process from these sources I'm in no way surprised that the outcome is what it is. I could be all mistaken (no first-hand expirience) but the pieces match up pretty well...
I checked both links...both programs have about 1/3 of their bugs left unpatched. Yes, IE has more bugs, that's no secret. There are more linux fanboy hackers out there trying to destroy MS, also a fact. I expect more bugs in a more widely used program with a known contingency of "enemies". The interesting thing to me is that both programs have 1/3 of the vulnerabilities unptched. While you're at it, take a look at the Firefox one as well. FireFox Nice job Firefox 1.X, only on the market for a few months and already 4/5 security flaws are unfixed? Cleary this is not an appropriate measure.
See, I knew something like this would come out. That's why I told you to look beyond the pretty pie charts and actually read the bug descriptions. If you had done that you'd know that most bugs listed for Mozilla are spoofing vulnerabilities (display a wrong URL in status-bar and such) while most bugs listed for IE are actual remote code execution vulnerabilities.
Seriously though, SP2 is a security improvement for the people previously running with no firewall. I don't think you can logically argue against that. Those of us behind a firewall already, also running antivirus are probably not in any better situation, I agree.
Yes, I can logically argue against that. The "security improvement" is a bunch of long overdue bugfixes (some of which broke other things) and a half-baked implementation of a desktop firewall that, among other problem, even kicks in too late (machines were reported to be infected during OS-install).
Wake me up when MS stops the patchworking and actually overhauls their developement process in order to stop at least the most humiliating bugs from happening. Tools and frameworks to automatically avoid whole classes of buffer overflows have been available for quite a while. I can only guess why MS isn't implementing these and my guess would be that they tried but stepped back from it because the tools have likely marked whole components as "throw away and try again". The other option (just as likely) would be that they have never tried and just don't care.
So the people who write the code for both places deserve no respect for the work they do?
That's the exact problem. I highly doubt that anyone at MS feels personally responsible for the IE mess. The emberassment would hardly be bearable for a single person anyways...
Yeah, there are bugs in both programs, and yes both of them have serious bugs at times.
At times? Let me think, the number of critical IE bugs certainly goes in the mid 2-digit range (maybe they've even hit 3 digits already?).
How many remotely exploitable Mozilla bugs have there been? I don't remember a single one so if there were any it must have been few. Now compare the developement models of the two. IE is backed up by a multi-billion dollar company that could very well afford proper Q/A... need I say more?
both IE and Firefox have been doing ok lately at getting patches for them
Gimme a break.
Compare this to this.
And be sure to look past the pretty pie charts for the actual vulnerability descriptions.
And SP2, with its improved security
Ok, nevermind. Why am I even talking...
it seems like we could be a bit more fair around here and at least either treat both browsers as if they suck, or treat them both with respect.
I'm touched by your call for humanity.
But they're friggin browsers. That's software, not people, mmkay?
The reason why people treat IE and Mozilla so differently is because IE does indeed suck bad and Mozilla does indeed suck far less. People are stunned that a multi-billion dollar company constantly refuses to apply proper QA to their software but instead sells expensive packages that are so bug-ridden that many real developers would be ashamed to only call it a "beta".
Back on topic:
These three "bugs" in the story (two of which have been fixed long ago, before v1.0) are pretty ridiculous compared to what MS comes up with every couple weeks. None of these Moz-bugs would allow a remote attacker to execute code on your box. Most remote IE-exploits that I have seen allow an attacker to do just that.
Therefor, the IE codebase (and the company responsible for it) deserve
no respect whatsoever.
Just my personal observations.
I certainly hope you don't login to the GUI as root?
Why would anyone want to do such a stupid thing?
Well, despite you're just a flaming AC I'll take the time and respond...
"1. You choose and know what will be running, including all libraries (starting from glibc), patches, compiler and interpreter versions"
That seems good, provided you are a real expert on all those fields. I bet you aren't, so you are doomed to make bad choices here.
Guess what, it's my job and I'm getting paid to be an expert on "all those fields" (which really is just advanced unix knowledge).
"2. When something breaks you know where to look because you set it up."
Probably a good reason. But then again, only *you* know that. If I were your boss this thing only is enough for me to fire you. I can and even want to have critical people because of his technical knowledge on the field and his work ability, but I don't want someone to be critical because of his knowledge of my company innerhoods, the one persons that works in a way that makes him unfireable is fired as soon as this is discovered so he doesn't have time to make things worse.
Ever heard about documentation?
If you don't trust your staff that's a different story and you probably
have bigger problems then.
"3. When working with pkg managers it can be hard to repeat an exact installation of what you blessed to be your stable environment."
That's bullshit. And it is such a bullshit that it can only mean that you have no idea about what a package manager is for, how does it works and which choices do you have. Then, all what you say about deploying you own LFS-like boxes is tainted from your unknowledgeability, and then not to be taken seriously. What package manages are FOR is (among other things) to achieve repeatability. I can (and do) deploy "clonic" boxes out from CVS (for config files) and package manager lists (either form rpm and/or dpkg) with total asurance of the results. You can't, OK, that's your problem, don't blame the tools you don't know about.
Dude, I've been working with kickstart (RedHat) and FAI (debian) for over a year. If you had that expirience you'd probably know that after a while you come to the point where you have to divert from the distro branch just because you don't want to update that friggin glibc just yet and everything else starts to depend on the updated package.
So you end up with a custom repository and start backporting packages where it matters. RedHat is already lost at that point (maybe they're better nowadays but back then RPM-hell made me abandon it).
Debian/stable is indeed quite stable but when your (considerably complex) FAI framework breaks down the nth time because some of the scripting magic is not as robust as it should be you begin to realize that rolling your own tarball is just so much less pita.
"you can hardly rely on apt-get or rpm to still provide the exact set of software that you once had (without updates getting in the way that depend on other updates etc.)"
Don't talk about what you ignore. I bet you *never* have properly used Debian under a production environment, otherwise you wouldn't say that. I *do* work with RH, and I *do* work with Debian, and I can tell you that having an upgrade that breaks your system is neither rpm's nor dpkg's fault, but their respective's distribution policy. I had Red Hat shoot me in the face some four o five times in the past due to a faulty upgrade (not that the package upgrade failed but because the new version broke something else), because Red Hat envisions their systems in a certain way. That's to me a big NO-NO, so I neither install nor counsel people to do so except when extrictly needed (and I try to do all on my hand to avoid those situations); now, Debian's policy is quite different and as a result, I didn't have a faulty upgrade on Stable boxes for almost six years (it is not that I had it six years ago, but that I have used Debian only from six years ago).
Well, the article we're
Since none of the commercial middleware and relational database vendors support anything except the commercial "enterprise" distributions, running stock kernels and stock everything else, you're pretty much blowing hot air here. Unless you think that the multi-cpu Oracle systems running on RHEL and SLES aren't "real" servers, which would be a pretty interesting position to take.
These are not servers within your responsibility. You buy them as blackboxes and expect oracle-support to keep them running for you. More an "appliance" than a server to me and why not, as long as oracle pays for downtime.
I'll try to explain further, this is why it is essential:
1. You choose and know what will be running, including all libraries (starting
from glibc), patches, compiler and interpreter versions. No generic distro
package will be optimized for your purpose because no maintainer knows what
set of services is critical to you and what configuration options are
appropiate. You do not want to run public services with all kinds of
unnecessary modules and options compiled it (many of which could become
a security problem in the future).
2. When something breaks you know where to look because you set it up.
When the quarterly openssl hole is announced you get the patch and deploy
the new version without having to wait for a distro package to come out
and without having to audit the distro package (is it properly fixed, does
it break other stuff, does it depend on newest glibc that will upgrade half
your system to an unknown state?).
3. When working with pkg managers it can be hard to repeat an exact
installation of what you blessed to be your stable environment.
If you need to replicate a server you end up tar'ring it up anyways
because you can hardly rely on apt-get or rpm to still provide the exact
set of software that you once had (without updates getting in the way that
depend on other updates etc.)
So why not start from a well-defined base tarball in first place...
4. By diverting from the large population of default installations you evade
generic "mass"-exploits (worms).
5. Last but not least:
You do not want automatic updates on a server, period.
You setup and test the thing once, then it is a Running System.
There is no reason to "stay in sync" with anyone, as long as
your system ticks you would be a moron to change anything.
There are exactly two reasons to update a piece of software
on a live-system:
a) security problem (usually patch + recompile of the affected pkg)
b) you need an addtl service that depends on a newer version of something
Don't get me wrong, distros are fine for newbies, desktops, small/non-exposed servers and the like. For anything serious I wouldn't trust my business to someone who deploys distro updates (with depends) to a running prod. server.