At the moment C may be faster than X, but in a lot of cases, X (where X is an interpretted or VM compiled language) will eventually over-run C in terms of performance.
But when that day arrives, we'll all be too busy playing Duke Nuken Forever to get any code written
If Mike really did use the Gnutella name without permission, why doesn't someone sue him?
Because they can't sue. They don't have a registered trademark on the name "gnutella". Just brcause the name is in common use to describe the protocol doesn't make it a trademark.
For example, I'd get my ass sued if I made a new operating system and called it 'Linux2'.
Linus does hold a registered trademark on the term "linux" as used to refer to computer operating system software. Wether he's sue is a good question, but you'd certainly get a lot of bad press and stir up a lot of contraversy... much like this whole gnutella issue.
The key difference, however, is that gnutella has strong reputation and long history of miserable performance.... so a promise of a much better network that solves all the "old" problems of gnutella can win quite a bit more support than co-opting the name linux, which generally everybody likes (except maybe some folks in Redmond:)
Unholster the IANAL's and tell me why.
To sue for trademark infringment, one needs to have a trademark. Bearshare, Limewire and the others strongly against Mike don't. Linus Torrvalds does have a registered trademark.
The story of the linux trademark is also quite interesting.... briefly, a slimball named Della Croce registered "linux" as his operating system trademark in 1995, and attempted to extort fees from various cdrom distributors in 1996 (back then, most people bought compilation cdroms from Infomagic and others). Everybody was outraged. Most of the major linux companies filed a suit or provided assistance, and ultimately the trademark was assigned to Linus.
Since IANAL, I did gloss over the whole issue of registered vs non-registered trademarks, and what opportunities one might have to sue if a trademark is not registered. Maybe someone who knows about this will respond. But it's pretty safe to say that the term "gnutella" is not a trademark.
Here is a possible solution.... Well instead of trying to go after spammers go after the business that use them.
While you're dreaming, how about finding those idiots who actually BUY from spam. They are ultimately the incentive for sending spam. If only you could "educate" them not to buy.
... Redhat 7.2, ran Netscape, viewed a couple web pages. Looks like absolute crap! Don't tell me about getting new fonts
Redhat 8.0 (finally) has nice-looking fonts. It is true that the fonts sucked in previous versions, and doing anything about it was a X/fonts configuration nightmare. It seems highly unlikely that the old font problems will ever return (though the "linux" reputation for poor fonts will persist, just like Microsoft's reputation for the blue screen of death that plauged 95/97/Me/NT4)
I know that IE renders things "wrong", but because of those percentages, that makes it right, and everyone else wrong.
No, it's still wrong. Widespread, but wrong.
If gecko gains significant market share (eg, AOL ships it to millions of unsophisticated users) and khtml gets most of the macintosh market, Microsoft will eventually be pressured into fixing those wrong renderings. Increasingly, windows users are using the automatic updates (as well they should, given microsoft's inability to publish secure software), so fixes will probably be deployed quickly, and newer sites will say "best viewed with MSIE 7.0" (or whatever version fixed the bugs).... and guess who's going to be scrambling? All those non-standard websites!
So why can't Netscape/Gecko/Mozilla/etc render things the way I want them to? And until they do, I'm using IE.
Mozilla/Gecko emulates IE's wrong behavior quite well, and of course newer versions of Netscape are based on Gecko (not 4.7x as you would have tried in Redhat 7.2).
I want my browsing experience to be simple and powerful, but simple is more important.
Suit yourself.
I personally want my browsing experience to be free of flashy, annoying advertising... and I'm willing to spend some effort to dig into the "edit-preferences-advanced" settings to block those damn popups and turn off animations. I'm also willing to go to the trouble to install
privoxy, which really kills advertising!
Within the US, you are right that beyond Word 6 or maybe Word 95, not a lot of important new features have been added.
But Word 97 made the big switch to unicode (16 bit chars), and that is the big reason for the incompatible file format changes. So many outside the US might say that Word 97 was the last word in useful word additions.
Also, the popup blocker probably requires more code for the user-interface than for the blocking. It's simply refusing to run certain javascript commands (such as OnExit() or whatever it's called) if an option is set. It's a trivial patch.
It was at first, but it was changed to include a timer of some sort, so it wouldn't block "legitimate" popups.
Personally, popups and flashy ads waste a lot of time. A lot more time than the milliseconds that popup blocking code might take to execute.
Sometimes I end up using a windows machine and IE, and it's amazing how bad the web has become these days.
There's no reason not to implement both high-throughput scheduling for big servers and low-latency scheduling for desktops in the same kernel...
Obviously you did not read much of the linux kernel mail list discussion. Kernel developers want their desktops to remain responsive while they're recompiling the kernel.
Well, they also want multimedia apps and X to run smoothly when other non-interactive loads are placed on the system, but if you had read the discussion, you'd see that nearly every message in the first half mentions dragging a big xterm window while a full multi-threaded kernel recompile is in process.
So, obviously SOME people do need low-latency desktop performance AND high-throughput to do real work at the same time. And that happens to be all kernel developers who recompile the kernel a lot!
Just because YOU never do anything that involves a lot of CPU time doesn't mean others do not also.
Replacing proprietary software with open source could help quite a bit.
Please explain how replacing proprietary system, that's already been purchased, with free software results in a net savings?
Now I could see if you decided to use free software for new systems, rather than purchasing more proprietary software, but replacing existing software??
And don't go on about forced upgrades. If you're considering something as drastic as ripping out proprietary software and replacing it with free software, simply not upgrading the existing proprietary software (despite minor problems down the road) is certainly within the realm of possibility.
Having written a bit of free software myself, I can tell you that having lots of "bleeding edge" users running code as it's updated in CVS is a big contribution.
Even when they don't really describe the bug well, finding out about a new bug within HOURS, while the code is still fresh, really helps. It also makes coding more exciting, having people trying out the new code within hours.
Sure, there are lots of ways to more directly contribute... but in just simply using the software, running truely on the bleeding edge (updating to CVS every couple days, or ever time something interesting happens on the mail list) really helps developers find out about bugs while they're still easy to fix and it really increases the overall energy level or momentum of the developers working on the project.
Yes, that's a big part of the appeal. But, spell_check != formal_news. You need to do so much more to be a formal news site. You're so far away from being a formal news site that the tiny incremenatal change of spell checking really is a tiny drop in the ocean of change needed to become "formal". But it would make reading slashdot less irritating (and there's spell checking software that make this easy, unlike avoiding dups...)
I just feel like people who make these arguments want to fundamentally change the very nature of what Slashdot is!
You're saying that integrating a spell checking into the story posting process would fundamentally change the very nature of slashdot.
Now if you were to investigate all stories, use a formal writing style, write your own copy instead of primarily using the submission text, and dozens of other things... then you'd be talking about changing the nature of slashdot. Integrating a spell checking into the story posting, and even into comment posting and posting to the story submission just isn't going to change the fundamental nature of slashdot.
What makes you think anyone was really leaned on to install the patch?
The C|Net article... you know, the one slashdot linked to....
Quoting from the article:
"They were a good resource in helping us make sure that the protection was put in place," Greg Olson, chairman and co-founder of Sendmail Inc., said of the response staff at NIPC, now with the directorate. "You need to contact a lot of people and make sure they understand this is important and (make sure they) apply the patch." Sendmail Inc. develops a proprietary version of the mail server.
Would that necessarily be good? An unexamined patch might contain nearly anything.
Are you serious?
Are you really suggesting they should not do everything reasonably possible to get the patch widely installed? Have you not paid attention to the last several worms that exploited well known problems months after the patches had been announced but never widely installed? Do you not understand what a remote root exploit is? Have you no concept of sendmail's massice installed base handling 50% to 75% of all email messages?
I think you've got to admit that a business model which financially rewards the creators of content is likely to be more sustainable in the long term than one based on 'everybody gets the content for free'.
Yes, today plenty of music is being produced under a business model where the vast majority of artists go broke, some make about the same as normal jobs, and only a very few actually make really desirable income.
Of course, most of the other "creators of content", producers, managers, technicians, distributors, retailers and so on are compensated.
Hmm - maybe copying music without giving anything back to the artist ought to be socially unacceptable, or maybe even illegal?
This would be a serious setback to the established music industry, where the expenses recoupable from artists outweigh royalties in the vast majority of cases.
1. There is no interim action. While you wait for me to fix the bug, everyone in the world is vulnerable without the option of shutting down that service or taking additional safeguards against the bug. This could be days to months of insecurity. What makes you think DHS is always going to be the first to discover an exploit?
In theory, you are right.
In practice, every major attack in the last few years has occured long after a patch was released and admins/users had plenty of time to update (but did not install the patch for a variety of reasons).
2. I don't see how a Government Department is going to succeed where Public Voice has failed.
The entire security process ("public voice", security advisories, news coverage, and so on) has failed time and time again to get patches widely deployed before a major attack is launched. Failure to install patches is such a large problem that it drarfs all others (especially the minor ones that I didn't bother to quote).
It appears that the DOH does indeed have quite a bit of clout to persuade many admins to apply the patch quickly.
3. How is this process going to be handled when there is no Company supporting the code? I'm uncertain that this will be supportive in the OpenSource Model.
In theory, a big problem.
In practice, only actively maintained open-source projects are widely deployed. In practice, open source and free software projects have a long history of releasing fixes very rapidly... often much more rapidly than proprietary software.
It's precisely the threat of publicity that pressures vendors into patching their compromised software quickly.
If you look at the last couple years, the real problem hasn't been how quickly the vendor released the patch. (extreem vendor denial/delay was a large problem long, long ago). The problem has been that long after the patch was released, most admins/users had not applied it.
In the last few years, every major incident was not a result of a vendor taking too long releasing the patch. All the real problems have been due to a failure to communicate the availablity of the patch and failure of admins and users to update their software with the patch (for a variety of reasons, but the problem of unpatched systems is the same regardless of the reason the patch was not installed).
According to the articles, the DOH is using its clout to get admins to install this patch quickly. Lengthening the usual 3-4 weeks to 8-9 weeks in this case is a non-issue compared with the problem of getting every sendmail installation to actually install the patch.
It appears they are making progress on the REAL problem.
If that threat is relieved, by Official KeepYerDamnMouthShut Orders from a government body, those same vendors may start to think "Phew, now we can wait for the next upgrade".
That certainly doesn't appear to have happened here. Sure, the process took 8-9 weeks, rather than the usual 3-4 weeks or the "holy shit, there's exploit code on bugtraq" schedule.
Honestly, if those extra 5 weeks spent somehow result pressure on admins to install the patch quickly (rather than pressure not to risk their job making non-urgent changes to the critical email server), then it was time well spent.
This is Not a Good Thing.
Needlessly lengthening the delay would not be good. Going back 5-10 years ago, when vendors primarily used denial instead of releasing patches would be not a good thing.
But in this case, the trade-off appears to be that the DOH is using its clout to put a sense of urgency into admins (and their managers, who have historically been the larger problem in not accepting the cost and risk of applying patches until after a successful attack).
If they are successful in getting admins to widely deploy the patch quickly, and all it cost was a few weeks delay and some "big brother" spooks involved to exert pressure to get everyone upgraded, then I'd say it's by far a net win.
What's really cool is that they're leaning on admins to actually install the patch quickly.
Sure, it sucks to be "left in the dark" while vendors slowly come up with patches. Sure, you'd like the vendor's "feet held to the fire" to write, test and release the patch as quickly as possible. If that's painful for them, well, they dman well deserve it since they wrote the but in the first place. Or at least that's how it feels to you and me, small-time admins (at least me) who find out when the patch is released weeks or even months (2 in this case) after the initial discovery. It's easy to feel this way.
But historically, the biggest problem has not been the timeliness of releasing patches. The REAL problem has been that most admins/users do not install the patch until _after_ an attack has begun.
Pathces not getting applied is by far the largest problem. It dwarfs the problem that of several weeks elapsing between initial discovery to patch availability to public announcment (where the "problem" is that some black-hats might have known for some time and might have been quietly exploiting systems for a long time).
Sure, it rubs you and me the wrong way and might even hurt our feelings a bit that we were kept in the dark for 2 months. Yeah, it sucks that our servers were on-line and open to attack all that time (and long before initial discovery by ISS). But get over it.
In the larger picture, what has always mattered much more is getting all or most systems patched. That has historically been a giant problem. Admins don't patch, for one reason or another. Some are overworked, a few might be lazy, many don't find out about the patch, and in a great many cases the admin isn't authorized to make "unnecessary" changes, or would be risking his job patching a critical system before upper management felt it was urgent.
In the past, only a widespread attach has given most admins that sense of urgency to apply the patch. That sucks.
The DOH using its clout to provide that sense of urgency to apply the patch before an attack begins is a good thing. To the extent they pull this off (it's still too early to judge), they'll have gone a long way towards solving the largest computer security problem.
So whine all you like about being left in the dark. Mod me down for going against the flow here on slashdot. Complain about the extreemly unlikely chance that some black-hat knew before ISS and was quitely and undetectably exploiting the bug. But don't try to deny that by far, by at least an order of magnitude, the largest problem has been a widespread failure to apply released patches until after a highly successful and widespread attack.
To the extent the DOH puts pressure on admins to install this patch before an attack, they will have made a huge improvement in overall security. The several weeks from initial discovery until patch availablity and security advisory just isn't significant in comparision.
So, the mandate will be patch first and question whether it will destroy the server and its data later?
There are reasons why not every patch is applied without thought.
This isn't a Microsoft service pack. It isn't even a matter of "replace whatever you're running with the latest version".
A new version with the fix (and other smaller improvements) was released AND small fix-only patches were released for many older versions of sendmail in widespread usage.
My own server was running 8.11.6, and in the move to 8.12.x sendmail changed to running two processes... the main one without root privs and another with root privs to handle just the parts that can't be done without root access. Supposedly this will make sendmail more secure to unforseen problems in the future.
Upgrading from 8.11.x or older to 8.12 is not really easy, but I personally managed it in about an hour. But if I had wanted to keep things exactly as they had been, I could have obtained the patch for 8.11 and just installed the new binary, and kept my configuration exactly the same. That patch only fixes this one little buffer overflow.
Re:Yay for biases? +1 for an article, though.
on
Longhorn M4 Build Review
·
· Score: 4, Interesting
Does any *nix installation *not* start you off as Root, with the ability to create more accounts?
Most have you create non-root accounts at installation. All RedHat installers in the last couple years have done this.
You know the admin password. Meaning, the user will know the admin password.
So, non-issue.
If you misunderstand the issue (that by default the user is logged in with full admin privs) to be the an issue user _could_ login with admin access, then it is a non-issue.
But in fact, the issue is that ordinary, unskilled users will by default be running with full admin privs, rather than a set of privs that are adaquete for the tasks they normally would do and protect them from accidental mistakes and malicious code they may be duped into running. Some people might say "well, they chose to run as admin", but in fact they just clicked-their-way-through without paying much attention. Good design and security practice is the make the default settings as secure as possible. This is a basic, well established principle... on of those things all Microsoft developers were supposedly off to "training" for a month after Bill's famous "trustworthy computing" memo. But it appears that even now, Microsoft is still making the default for ordinary users to run with full admin privs.
For sake of comparison, in Redhat 8, users are likely to run the system as ordinary users. The installer encourages them to create non-root accounts. The first time the GUI is started, it will complain with a warning dialog box if the user is running as root. Thing like this warning go a long way to helping protect users. Some other apps will also complain if the user is running as root. The other notworthy feature in Redhat 8 (and possibly other distros) is that GUI-based configuaration programs prompt for the root password, and a security manager maintains the root access for a while so the user isn't punished by having to retype the root password constantly as they tweak settings. And most linux-based apps are designed to run without root access. All of these factors work together, most of the time, to cause users to run without root privs and all the unnecessary risks associated with it.
Compare to Microsoft land, where by default the unskilled user runs with full admin privs, and nothing warns them and attempts to get them to "do the right thing".... and historically lots of things "just don't work" unless the user logs out and logs back in as the administrator. Those conditions all conspire to drive ordinary users to run with admin privs (when 99% of the time it's not necessary and needlessly opens them to unnecessary risks).
Ordinary users just want things to work, and they usually take the path of least resistance. Modern linux-based systems make that path relatively secure. But Microsoft, despite their "trustworthy computing" marketing still appears to take the easy approach, where they make the easiest path one with unnecessary security risks.
It's not the lower power / current / whatever. It's the lower frequencies on the AC lines.
The two are related. All those generators interconnected to each other via the power lines, turn together in synchronized motion. If the sum of all power consumption is not matched by the correct rate of energy input (ultimately, torque applied) to the system, those generators will necessarily slow down.
The AC frequency is directly determined by the rotational speed of the generators. The magnetic field of the rotor induces that AC current in the stator windings as it turns, so the speed of rotation must be maintained if the AC frequency is to be correct.
Why they don't disconnect some loads (eg, rolling blackouts) to keep the consumption balanced with their energy input is a good question?
The really interesting thing about power grids is how the all those generators work together in synchronous motion. Every single one of them turns at the same speed and all those rotors are at (almost) exactly the same angular position at the same instant (or equivilant angular position in the case of different generator designs with different numbers of windings). If any one generator goes not receive enough torque applied, it acts as a motor and the rest of the grid supplies power to it to keep it turning in sync motion with the rest.
The power grid, as a whole, must be very carefully managed to keep the energy input (torque on the generators) balanced with the consumption of all the loads. If it is not managed properly, as appears the be the case here, the frequency can drift. That's actually a very big problem, not just because of all those clocks and old televisions using the line frequency for timing, but because all those transformers and motors attached to the grid were designed to operate at the specified frequency. As the frequency lowers, approaching even somewhat closer to DC, the magnetizing currents increase. That puts a lot of extra stress on all those motors and transformers. Very bad.
It's also worth noting that the cmd640 chipset was used on late 486 and early pentium motherboards. Few, if any, new computers have used this buggy chip since the mid 90's.
then it will reduce the amount of spam that gets through to potential customers, and hence make each spamming less profitable.
While we're dreaming about ways to make spam less profitable, don't forget about somehow educating new users not to fall for stupid scams just because they saw it on the computer.
ISPs are actually in a pretty good position to distribute that sort of educational message to all new users.
Slashdot Mirror
...dupes!
But when that day arrives, we'll all be too busy playing Duke Nuken Forever to get any code written
Because they can't sue. They don't have a registered trademark on the name "gnutella". Just brcause the name is in common use to describe the protocol doesn't make it a trademark.
For example, I'd get my ass sued if I made a new operating system and called it 'Linux2'.
Linus does hold a registered trademark on the term "linux" as used to refer to computer operating system software. Wether he's sue is a good question, but you'd certainly get a lot of bad press and stir up a lot of contraversy... much like this whole gnutella issue.
The key difference, however, is that gnutella has strong reputation and long history of miserable performance.... so a promise of a much better network that solves all the "old" problems of gnutella can win quite a bit more support than co-opting the name linux, which generally everybody likes (except maybe some folks in Redmond :)
Unholster the IANAL's and tell me why.
To sue for trademark infringment, one needs to have a trademark. Bearshare, Limewire and the others strongly against Mike don't. Linus Torrvalds does have a registered trademark.
The story of the linux trademark is also quite interesting.... briefly, a slimball named Della Croce registered "linux" as his operating system trademark in 1995, and attempted to extort fees from various cdrom distributors in 1996 (back then, most people bought compilation cdroms from Infomagic and others). Everybody was outraged. Most of the major linux companies filed a suit or provided assistance, and ultimately the trademark was assigned to Linus.
Since IANAL, I did gloss over the whole issue of registered vs non-registered trademarks, and what opportunities one might have to sue if a trademark is not registered. Maybe someone who knows about this will respond. But it's pretty safe to say that the term "gnutella" is not a trademark.
Only if you're the one doing the striking, with little or no risk of retribution.
While you're dreaming, how about finding those idiots who actually BUY from spam. They are ultimately the incentive for sending spam. If only you could "educate" them not to buy.
What is wrong with last year's bill that would have outlawed forged headers and intentionally deceptive subject lines on bulk email?
of course in windows, nobody needs to open/edit large files and it's ok if the system mysteriously locks up all the time.
Or at least it was in the days of Windows 3.1... when you last tried SLS or an early Slackware linux distro.
Redhat 8.0 (finally) has nice-looking fonts. It is true that the fonts sucked in previous versions, and doing anything about it was a X/fonts configuration nightmare. It seems highly unlikely that the old font problems will ever return (though the "linux" reputation for poor fonts will persist, just like Microsoft's reputation for the blue screen of death that plauged 95/97/Me/NT4)
I know that IE renders things "wrong", but because of those percentages, that makes it right, and everyone else wrong.
No, it's still wrong. Widespread, but wrong.
If gecko gains significant market share (eg, AOL ships it to millions of unsophisticated users) and khtml gets most of the macintosh market, Microsoft will eventually be pressured into fixing those wrong renderings. Increasingly, windows users are using the automatic updates (as well they should, given microsoft's inability to publish secure software), so fixes will probably be deployed quickly, and newer sites will say "best viewed with MSIE 7.0" (or whatever version fixed the bugs).... and guess who's going to be scrambling? All those non-standard websites!
So why can't Netscape/Gecko/Mozilla/etc render things the way I want them to? And until they do, I'm using IE.
Mozilla/Gecko emulates IE's wrong behavior quite well, and of course newer versions of Netscape are based on Gecko (not 4.7x as you would have tried in Redhat 7.2).
I want my browsing experience to be simple and powerful, but simple is more important.
Suit yourself.
I personally want my browsing experience to be free of flashy, annoying advertising... and I'm willing to spend some effort to dig into the "edit-preferences-advanced" settings to block those damn popups and turn off animations. I'm also willing to go to the trouble to install privoxy, which really kills advertising!
But Word 97 made the big switch to unicode (16 bit chars), and that is the big reason for the incompatible file format changes. So many outside the US might say that Word 97 was the last word in useful word additions.
It was at first, but it was changed to include a timer of some sort, so it wouldn't block "legitimate" popups.
Personally, popups and flashy ads waste a lot of time. A lot more time than the milliseconds that popup blocking code might take to execute.
Sometimes I end up using a windows machine and IE, and it's amazing how bad the web has become these days.
Why not?
It's worked so well for a certain software company
Obviously you did not read much of the linux kernel mail list discussion. Kernel developers want their desktops to remain responsive while they're recompiling the kernel.
Well, they also want multimedia apps and X to run smoothly when other non-interactive loads are placed on the system, but if you had read the discussion, you'd see that nearly every message in the first half mentions dragging a big xterm window while a full multi-threaded kernel recompile is in process.
So, obviously SOME people do need low-latency desktop performance AND high-throughput to do real work at the same time. And that happens to be all kernel developers who recompile the kernel a lot!
Just because YOU never do anything that involves a lot of CPU time doesn't mean others do not also.
Please explain how replacing proprietary system, that's already been purchased, with free software results in a net savings?
Now I could see if you decided to use free software for new systems, rather than purchasing more proprietary software, but replacing existing software??
And don't go on about forced upgrades. If you're considering something as drastic as ripping out proprietary software and replacing it with free software, simply not upgrading the existing proprietary software (despite minor problems down the road) is certainly within the realm of possibility.
Even when they don't really describe the bug well, finding out about a new bug within HOURS, while the code is still fresh, really helps. It also makes coding more exciting, having people trying out the new code within hours.
Sure, there are lots of ways to more directly contribute... but in just simply using the software, running truely on the bleeding edge (updating to CVS every couple days, or ever time something interesting happens on the mail list) really helps developers find out about bugs while they're still easy to fix and it really increases the overall energy level or momentum of the developers working on the project.
Yes, that's a big part of the appeal. But, spell_check != formal_news. You need to do so much more to be a formal news site. You're so far away from being a formal news site that the tiny incremenatal change of spell checking really is a tiny drop in the ocean of change needed to become "formal". But it would make reading slashdot less irritating (and there's spell checking software that make this easy, unlike avoiding dups...)
I just feel like people who make these arguments want to fundamentally change the very nature of what Slashdot is!
You're saying that integrating a spell checking into the story posting process would fundamentally change the very nature of slashdot.
Now if you were to investigate all stories, use a formal writing style, write your own copy instead of primarily using the submission text, and dozens of other things... then you'd be talking about changing the nature of slashdot. Integrating a spell checking into the story posting, and even into comment posting and posting to the story submission just isn't going to change the fundamental nature of slashdot.
The C|Net article... you know, the one slashdot linked to....
Quoting from the article:
And also this similar article on MSNBC
Would that necessarily be good? An unexamined patch might contain nearly anything.
Are you serious?
Are you really suggesting they should not do everything reasonably possible to get the patch widely installed? Have you not paid attention to the last several worms that exploited well known problems months after the patches had been announced but never widely installed? Do you not understand what a remote root exploit is? Have you no concept of sendmail's massice installed base handling 50% to 75% of all email messages?
Yes, today plenty of music is being produced under a business model where the vast majority of artists go broke, some make about the same as normal jobs, and only a very few actually make really desirable income.
Of course, most of the other "creators of content", producers, managers, technicians, distributors, retailers and so on are compensated.
Hmm - maybe copying music without giving anything back to the artist ought to be socially unacceptable, or maybe even illegal?
This would be a serious setback to the established music industry, where the expenses recoupable from artists outweigh royalties in the vast majority of cases.
In theory, you are right.
In practice, every major attack in the last few years has occured long after a patch was released and admins/users had plenty of time to update (but did not install the patch for a variety of reasons).
2. I don't see how a Government Department is going to succeed where Public Voice has failed.
The entire security process ("public voice", security advisories, news coverage, and so on) has failed time and time again to get patches widely deployed before a major attack is launched. Failure to install patches is such a large problem that it drarfs all others (especially the minor ones that I didn't bother to quote).
It appears that the DOH does indeed have quite a bit of clout to persuade many admins to apply the patch quickly.
3. How is this process going to be handled when there is no Company supporting the code? I'm uncertain that this will be supportive in the OpenSource Model.
In theory, a big problem.
In practice, only actively maintained open-source projects are widely deployed. In practice, open source and free software projects have a long history of releasing fixes very rapidly... often much more rapidly than proprietary software.
If you look at the last couple years, the real problem hasn't been how quickly the vendor released the patch. (extreem vendor denial/delay was a large problem long, long ago). The problem has been that long after the patch was released, most admins/users had not applied it.
In the last few years, every major incident was not a result of a vendor taking too long releasing the patch. All the real problems have been due to a failure to communicate the availablity of the patch and failure of admins and users to update their software with the patch (for a variety of reasons, but the problem of unpatched systems is the same regardless of the reason the patch was not installed).
According to the articles, the DOH is using its clout to get admins to install this patch quickly. Lengthening the usual 3-4 weeks to 8-9 weeks in this case is a non-issue compared with the problem of getting every sendmail installation to actually install the patch.
It appears they are making progress on the REAL problem.
If that threat is relieved, by Official KeepYerDamnMouthShut Orders from a government body, those same vendors may start to think "Phew, now we can wait for the next upgrade".
That certainly doesn't appear to have happened here. Sure, the process took 8-9 weeks, rather than the usual 3-4 weeks or the "holy shit, there's exploit code on bugtraq" schedule.
Honestly, if those extra 5 weeks spent somehow result pressure on admins to install the patch quickly (rather than pressure not to risk their job making non-urgent changes to the critical email server), then it was time well spent.
This is Not a Good Thing.
Needlessly lengthening the delay would not be good. Going back 5-10 years ago, when vendors primarily used denial instead of releasing patches would be not a good thing.
But in this case, the trade-off appears to be that the DOH is using its clout to put a sense of urgency into admins (and their managers, who have historically been the larger problem in not accepting the cost and risk of applying patches until after a successful attack).
If they are successful in getting admins to widely deploy the patch quickly, and all it cost was a few weeks delay and some "big brother" spooks involved to exert pressure to get everyone upgraded, then I'd say it's by far a net win.
Sure, it sucks to be "left in the dark" while vendors slowly come up with patches. Sure, you'd like the vendor's "feet held to the fire" to write, test and release the patch as quickly as possible. If that's painful for them, well, they dman well deserve it since they wrote the but in the first place. Or at least that's how it feels to you and me, small-time admins (at least me) who find out when the patch is released weeks or even months (2 in this case) after the initial discovery. It's easy to feel this way.
But historically, the biggest problem has not been the timeliness of releasing patches. The REAL problem has been that most admins/users do not install the patch until _after_ an attack has begun.
Pathces not getting applied is by far the largest problem. It dwarfs the problem that of several weeks elapsing between initial discovery to patch availability to public announcment (where the "problem" is that some black-hats might have known for some time and might have been quietly exploiting systems for a long time).
Sure, it rubs you and me the wrong way and might even hurt our feelings a bit that we were kept in the dark for 2 months. Yeah, it sucks that our servers were on-line and open to attack all that time (and long before initial discovery by ISS). But get over it.
In the larger picture, what has always mattered much more is getting all or most systems patched. That has historically been a giant problem. Admins don't patch, for one reason or another. Some are overworked, a few might be lazy, many don't find out about the patch, and in a great many cases the admin isn't authorized to make "unnecessary" changes, or would be risking his job patching a critical system before upper management felt it was urgent.
In the past, only a widespread attach has given most admins that sense of urgency to apply the patch. That sucks.
The DOH using its clout to provide that sense of urgency to apply the patch before an attack begins is a good thing. To the extent they pull this off (it's still too early to judge), they'll have gone a long way towards solving the largest computer security problem.
So whine all you like about being left in the dark. Mod me down for going against the flow here on slashdot. Complain about the extreemly unlikely chance that some black-hat knew before ISS and was quitely and undetectably exploiting the bug. But don't try to deny that by far, by at least an order of magnitude, the largest problem has been a widespread failure to apply released patches until after a highly successful and widespread attack.
To the extent the DOH puts pressure on admins to install this patch before an attack, they will have made a huge improvement in overall security. The several weeks from initial discovery until patch availablity and security advisory just isn't significant in comparision.
There are reasons why not every patch is applied without thought.
This isn't a Microsoft service pack. It isn't even a matter of "replace whatever you're running with the latest version".
A new version with the fix (and other smaller improvements) was released AND small fix-only patches were released for many older versions of sendmail in widespread usage.
My own server was running 8.11.6, and in the move to 8.12.x sendmail changed to running two processes... the main one without root privs and another with root privs to handle just the parts that can't be done without root access. Supposedly this will make sendmail more secure to unforseen problems in the future.
Upgrading from 8.11.x or older to 8.12 is not really easy, but I personally managed it in about an hour. But if I had wanted to keep things exactly as they had been, I could have obtained the patch for 8.11 and just installed the new binary, and kept my configuration exactly the same. That patch only fixes this one little buffer overflow.
Most have you create non-root accounts at installation. All RedHat installers in the last couple years have done this.
You know the admin password. Meaning, the user will know the admin password.
So, non-issue.
If you misunderstand the issue (that by default the user is logged in with full admin privs) to be the an issue user _could_ login with admin access, then it is a non-issue.
But in fact, the issue is that ordinary, unskilled users will by default be running with full admin privs, rather than a set of privs that are adaquete for the tasks they normally would do and protect them from accidental mistakes and malicious code they may be duped into running. Some people might say "well, they chose to run as admin", but in fact they just clicked-their-way-through without paying much attention. Good design and security practice is the make the default settings as secure as possible. This is a basic, well established principle... on of those things all Microsoft developers were supposedly off to "training" for a month after Bill's famous "trustworthy computing" memo. But it appears that even now, Microsoft is still making the default for ordinary users to run with full admin privs.
For sake of comparison, in Redhat 8, users are likely to run the system as ordinary users. The installer encourages them to create non-root accounts. The first time the GUI is started, it will complain with a warning dialog box if the user is running as root. Thing like this warning go a long way to helping protect users. Some other apps will also complain if the user is running as root. The other notworthy feature in Redhat 8 (and possibly other distros) is that GUI-based configuaration programs prompt for the root password, and a security manager maintains the root access for a while so the user isn't punished by having to retype the root password constantly as they tweak settings. And most linux-based apps are designed to run without root access. All of these factors work together, most of the time, to cause users to run without root privs and all the unnecessary risks associated with it.
Compare to Microsoft land, where by default the unskilled user runs with full admin privs, and nothing warns them and attempts to get them to "do the right thing".... and historically lots of things "just don't work" unless the user logs out and logs back in as the administrator. Those conditions all conspire to drive ordinary users to run with admin privs (when 99% of the time it's not necessary and needlessly opens them to unnecessary risks).
Ordinary users just want things to work, and they usually take the path of least resistance. Modern linux-based systems make that path relatively secure. But Microsoft, despite their "trustworthy computing" marketing still appears to take the easy approach, where they make the easiest path one with unnecessary security risks.
The two are related. All those generators interconnected to each other via the power lines, turn together in synchronized motion. If the sum of all power consumption is not matched by the correct rate of energy input (ultimately, torque applied) to the system, those generators will necessarily slow down.
The AC frequency is directly determined by the rotational speed of the generators. The magnetic field of the rotor induces that AC current in the stator windings as it turns, so the speed of rotation must be maintained if the AC frequency is to be correct.
Why they don't disconnect some loads (eg, rolling blackouts) to keep the consumption balanced with their energy input is a good question?
The really interesting thing about power grids is how the all those generators work together in synchronous motion. Every single one of them turns at the same speed and all those rotors are at (almost) exactly the same angular position at the same instant (or equivilant angular position in the case of different generator designs with different numbers of windings). If any one generator goes not receive enough torque applied, it acts as a motor and the rest of the grid supplies power to it to keep it turning in sync motion with the rest.
The power grid, as a whole, must be very carefully managed to keep the energy input (torque on the generators) balanced with the consumption of all the loads. If it is not managed properly, as appears the be the case here, the frequency can drift. That's actually a very big problem, not just because of all those clocks and old televisions using the line frequency for timing, but because all those transformers and motors attached to the grid were designed to operate at the specified frequency. As the frequency lowers, approaching even somewhat closer to DC, the magnetizing currents increase. That puts a lot of extra stress on all those motors and transformers. Very bad.
It's also worth noting that the cmd640 chipset was used on late 486 and early pentium motherboards. Few, if any, new computers have used this buggy chip since the mid 90's.
While we're dreaming about ways to make spam less profitable, don't forget about somehow educating new users not to fall for stupid scams just because they saw it on the computer.
ISPs are actually in a pretty good position to distribute that sort of educational message to all new users.