If you look at the current releases that matter (i.e. 6.2, 7.2, 7.3), they're all going to get about two-and-a-bit-years of errata support anyway.
I think people are being overly paranoid - I see RH's EOL statement as a guarantee of a minimum of 12 months support, even for the x.0 releases, and the examples of support lifetimes for their x.final releases as evidence that future x.final releases will probably have similar support lifetimes (i.e. 2-3 years).
Also, Microsoft have recently postponed the EOL date for NT 4, and so if an EOL date was particularly unpopular with Red Hat's paying customers they'd respond similarly (they've left that option open in their statement). It's good business sense to do so.
If there's sufficient demand for it (i.e. paying customers or plenty of hacker kudos), I'm sure there will be. I've been backporting packages from Red Hat's beta/rawhide and other releases for my own use for a few years now.
Uh, but by the time 8.0 is EOLed (31 Dec 2003), it won't be the latest any more. In fact, 8.2 or 8.3 should be out by then.
The unwritten rule of RH is that if you want stability, you use the last point release. This used to be x.2, but 7.3 complicated things a little. x.0 is regarded as a technology preview ("hey, we put lots of exciting new stuff in, and we're still working out what we broke!") and x.1 as a public beta ("uh, we think we've fixed all the howlers in x.0 now. Try this and let us know if there's anything that needs to be fixed in x.2").
ok, so you exploit a buffer overflow in xmms, then what? how many people are running xmms as root?
I can think of a couple of mechanisms that mean that it wouldn't be required for either your MP3 player or P2P client to be running as root, or for their binaries to be user-writable.
Firstly, the buffer overflow code embedded in an infected MP3 could exploit a local root/Administrator vulnerability in order to escalate the privileges of the player.
Secondly, you could not worry about infecting binaries at all, and just rely on the player or P2P client reading (and therefore being exploited by) the infected MP3 every time it's started (e.g. 'xmms./*.mp3' which would include 'infected.mp3' somewhere in that list)
Personally, I'm skeptical that 'hydra' exists _right now_, and I believe GOBBLES real message is to the script kiddies constantly defacing the RIAA's website recently - "stop doing that, or the RIAA might get round to doing something like *this*". What GOBBLES has proposed is difficult, and error-prone, but feasible IMHO.
a) the deposit b) the final payment in order to own the car.
Total cost of credit tends to add 10-20% onto the screen price if you buy the car at the end of the credit period. Alternatively, you can think of it as renting a car for two years for about the same monthly rate as a weekend rental.
Personally, I'm happy with my nice year old 3K GBP car that costs me under 2K GBP p.a. to run, including tax, petrol, repairs, servicing, depreciation and insurance. Oh, and there's no interest or repayments due as I bought it for cash.
In the quarters ending Nov 30, 2001, Feb 28, 2002, May 31, 2002, and Aug 31, 2002, Microsoft paid $4,423,000,000 in tax.
Where did you find these figures? I've looked in the most recent 10-Q and 10-K filed with the SEC but my reading doesn't agree with your figures.
I was going on various articles I've read along the lines of this one.
If your figures are correct, that would mean they're being taxed at an effective rate of ~56% (annual revenues of ~28 billion US$). I thought the US was the nation of *low* taxation compared with us savages over here in Europe! Even Microsoft's SEC filings only admit an effective taxation rate of ~33%...
The argument over whether the GPL is a "Public Domain" license is a strawman. It isn't, and it was never intended to be. Microsoft are quite correct about that, and that the BSD license is pretty much what a PD license should be.
Now, I gather in the US, the present legislation means that publicly-funded software development must be placed in the public domain, which would seem to exclude the GPL.
The question though, is much more fundamental; should publicly-funded software development be "public domain"?
On one hand, people have paid the taxes that funded the development, so they should get all the benefits. The most efficient way of doing this is to make the software Free and make sure that derivative products stay Free. And, as a bonus, it doesn't even stop proprietary software manufacturers from learning from it.
On the other hand, proprietary software manufacturers pay taxes too, so they should have the same rights.
On the other, other hand, most corporations of Microsoft's size actually pay very little in the way of tax, and will employ embrace-and-extend strategies given half the chance. Eventually, this screws over the state and therefore the people as a whole.
For these reasons, it's my belief that publicly-funded software development should be licensed under GPL-like licenses, unless there's a compelling reason not to do so. And the original developer and a proprietary software manufacturer are always at liberty to agree a mutually agreeable alternative license if the main license doesn't suit the latter party.
An example of code which should probably be released under a LGPL or weaker license would be software to handle a new file format or a new network protocol. In these cases, it's probably more efficient to license it under a more PD-oriented license such as the LGPL or BSD license so that the code may be re-used and the likelihood of incompatible deviations from the reference implementation greatly reduced. In brief; "use the right license for the job" - even RMS wrote something along these lines, but I can't seem to find it right now...
1. Revisioning. The ability to use different patch levels or versions. The ability to see how much space these different versions are taking up. Hard drive space is cheap, and I'm amazed an enterprise customer hasn't demanded this yet from Red Hat.
rpm's --repackage feature appears to have this intention behind it. Unfortunately, it doesn't appear to work here as the GPG and MD5 signatures aren't redone.
2. Security Policy. RPMS and other package formats sometimes come with scripts to do necessary post-install stuff. It would be nice to have a seperate userspace library to handle the 'common' things that might be in these scripts like running ldconfig or mkfontdir. This way, it would be simple enough for the rpm tool to give you a rundown of what 'actions' needs to be done to install this application security-policy wise. Ideally most scripts would become superfluos and only used it really odd situations. And in those odd cases you can read through the script yourself.
RH have begun to do this with things like chkfontpath, chkconfig, so I think they're aware of it...
--
I've built a couple of boxes using GA-8PE667s
on
Hardware Bits
·
· Score: 2
...and they're pretty sweet, IMHO. I built them a couple of months ago, so maybe I'd wait for a dual-channel DDR board now.
Red Hat 8.0 supports them out-of-the-box - Promise RAID controller, ALC650 sound, Intel Ethernet. Debian 3.0 doesn't seem to support the ethernet (it's on the CNR bus, apparently). Promise supply a binary module for the RAID controller, but there doesn't really seem to be any point - the hard bits are done in software anyway, so either use Linux ideraid or md and be done with it. I've gone with md, which also allows me to have mixed RAID0 and RAID1 devices using only 2 discs (not perfect resiliance, but good enough for my needs).
I threw a Celeron 1.7G in one machine and a P4 2.40B in the other.
The only thing I've found that doesn't appear to be terribly well supported is the environment sensor. I haven't tried the smartcard/memory card interface yet, nor the USB2.0 ports.
One thing to note is that the AGP slot is 4x, which limits you to 1.5volt cards - Geforce, Radeon, or Matrox, essentially.
...is the net conservation of resources and energy by the use of semiconductors. For example, if by having a PC and internet connection at home, it becomes possible to work from home, I wouldn't be surprised if the breakeven point between that and driving to work was reached very quickly.
... ClearType...requires a set pixel layout, which traditional CRTs don't have.
Actually, I prefer ClearType on my Sony monitor, but not on my "regular" monitor at work.
I was going to write saying exactly the same thing. I've used Xft's sub-pixel (aka ClearType-alike) rendering on my laptop for some time now. When I got a 20" Sun monitor (Sony Trinitron tube), I thought "hey, I wonder how s-p rendering looks on this, given it has a rectangular RGB pattern?", not really expecting it to work. Somewhat to my surprise, it does work, arguably better than a TFT!
I've always defined AmigaDOS as dos.library, the shell commands and a few other bits and pieces, whilst AmigaOS includes AmigaDOS but also adds intuition, exec, Workbench and all the other standard bits.
In theory, yes, the Working Time Directive prevents employers from forcing their employees to work long hours.
In practice, it appears to be commonplace to be asked to sign a waiver of your employee rights when you apply to join a company. This happened to me and it (amongst a few other things) made me reject the company at that point.
I have willingly worked long/anti-social hours to help out in a crisis or special circumstances, but I refuse to work that way as a matter of course.
Essentially, the secret (i.e. the password) is converted into a value that intercepts an axis of a n-dimensional graph. m points in n-dimensional space are then generated such that they lie in a straight line on a single plane. You can then distribute the values of the m points safe in the knowledge that you need at least n of them in order to calculate the point of interception of the secret.
So, m > n, and m is the number of people to whom you give the secret, n is the number of people which will be required to reconstruct the secret.
That plane must be a hyper-plane, with n-1 dimensions.
n dimensions, by my reckoning (think of a 2-dimensional graph - you'll need two points to determine the line and therefore the point of interception).
What exactly is the secret? Point of interception with what?
Um, with a chosen axis where all but one of the variables=0. For example, with a 2-dimensional graph, you might choose the y-axis.
Read Eric's explanation above; he does a better job of it than me. Failing that, read Shamir's paper.;-)
Heh. See, that's why I apologised for my rusty and vague maths.
It's been over 7 years since I've done any worthwhile maths (e.g. anything more complicated than simultaneous equations) so I think I've got a legitimate excuse.;-)
Any -minimally skilled- IT operator knows he should never tell passes to other people. But, what if this person dies? How can we safely store passwords so that those can be retrieved if "shit happens"?
Google for "secret sharing" and you'll find plenty of references. Essentially, the secret (i.e. the password) is converted into a value that intercepts an axis of a n-dimensional graph. m points in n-dimensional space are then generated such that they lie in a straight line on a single plane. You can then distribute the values of the m points safe in the knowledge that you need at least n of them in order to calculate the point of interception of the secret.
AFAIK, this is how things like launch codes for nukes are stored and distributed (to counter the twin threats of elimination of keyholders preventing nukes from being launched, and to prevent a single rogue keyholder launching without appropriate authorisation).
Apologies to the maths/crypto purists out there if my description is fuzzy, over-simplified, or plain wrong, but it's been a while...;-)
Being PICs or similarly simple devices, modchips for the Playstation and Dreamcast don't cause the display of banners. Someone who's seen the Xbox modchip would have to answer for that device, but I wouldn't expect it to be different in this regard.
If I install this mod chip, will the XBox appear any different to my wife, who would kill me if she knew I was voiding the warranty and possibly breaking a $200 "toy". In other words, will it run and play exactly as before, or will she notice that something's different?
That'll all depend on the design of the modchip, the ease of installation and, by implication, how good a job you make of the installation.
Certainly, the intentions of modchip designers are to not impair normal functionality, but bugs creep in, some can be difficult to install (risking permanent damage to the host console) and later software releases can sometimes detect the presence of a modchip and refuse to run until it is removed or disabled.
Unless you have $200 to risk (and more importantly, the wrath of your spouse!) I'd wait until it was out of warranty or get a "professional" installation. Of course, given the grey legal area in which these devices reside, it's sometimes hard to tell the difference between a professional installer and a chimpanzee with a soldering iron.;-]
Slashdot Mirror
I think people are being overly paranoid - I see RH's EOL statement as a guarantee of a minimum of 12 months support, even for the x.0 releases, and the examples of support lifetimes for their x.final releases as evidence that future x.final releases will probably have similar support lifetimes (i.e. 2-3 years).
Also, Microsoft have recently postponed the EOL date for NT 4, and so if an EOL date was particularly unpopular with Red Hat's paying customers they'd respond similarly (they've left that option open in their statement). It's good business sense to do so.
--
--
--
The unwritten rule of RH is that if you want stability, you use the last point release. This used to be x.2, but 7.3 complicated things a little. x.0 is regarded as a technology preview ("hey, we put lots of exciting new stuff in, and we're still working out what we broke!") and x.1 as a public beta ("uh, we think we've fixed all the howlers in x.0 now. Try this and let us know if there's anything that needs to be fixed in x.2").
--
I can think of a couple of mechanisms that mean that it wouldn't be required for either your MP3 player or P2P client to be running as root, or for their binaries to be user-writable.
Firstly, the buffer overflow code embedded in an infected MP3 could exploit a local root/Administrator vulnerability in order to escalate the privileges of the player.
Secondly, you could not worry about infecting binaries at all, and just rely on the player or P2P client reading (and therefore being exploited by) the infected MP3 every time it's started (e.g. 'xmms ./*.mp3' which would include 'infected.mp3' somewhere in that list)
Personally, I'm skeptical that 'hydra' exists _right now_, and I believe GOBBLES real message is to the script kiddies constantly defacing the RIAA's website recently - "stop doing that, or the RIAA might get round to doing something like *this*". What GOBBLES has proposed is difficult, and error-prone, but feasible IMHO.
--
Don't forget about
a) the deposit
b) the final payment in order to own the car.
Total cost of credit tends to add 10-20% onto the screen price if you buy the car at the end of the credit period. Alternatively, you can think of it as renting a car for two years for about the same monthly rate as a weekend rental.
Personally, I'm happy with my nice year old 3K GBP car that costs me under 2K GBP p.a. to run, including tax, petrol, repairs, servicing, depreciation and insurance. Oh, and there's no interest or repayments due as I bought it for cash.
--
Where did you find these figures? I've looked in the most recent 10-Q and 10-K filed with the SEC but my reading doesn't agree with your figures.
I was going on various articles I've read along the lines of this one.
If your figures are correct, that would mean they're being taxed at an effective rate of ~56% (annual revenues of ~28 billion US$). I thought the US was the nation of *low* taxation compared with us savages over here in Europe! Even Microsoft's SEC filings only admit an effective taxation rate of ~33%...
--
Now, I gather in the US, the present legislation means that publicly-funded software development must be placed in the public domain, which would seem to exclude the GPL.
The question though, is much more fundamental; should publicly-funded software development be "public domain"?
On one hand, people have paid the taxes that funded the development, so they should get all the benefits. The most efficient way of doing this is to make the software Free and make sure that derivative products stay Free. And, as a bonus, it doesn't even stop proprietary software manufacturers from learning from it.
On the other hand, proprietary software manufacturers pay taxes too, so they should have the same rights.
On the other, other hand, most corporations of Microsoft's size actually pay very little in the way of tax, and will employ embrace-and-extend strategies given half the chance. Eventually, this screws over the state and therefore the people as a whole.
For these reasons, it's my belief that publicly-funded software development should be licensed under GPL-like licenses, unless there's a compelling reason not to do so. And the original developer and a proprietary software manufacturer are always at liberty to agree a mutually agreeable alternative license if the main license doesn't suit the latter party.
An example of code which should probably be released under a LGPL or weaker license would be software to handle a new file format or a new network protocol. In these cases, it's probably more efficient to license it under a more PD-oriented license such as the LGPL or BSD license so that the code may be re-used and the likelihood of incompatible deviations from the reference implementation greatly reduced. In brief; "use the right license for the job" - even RMS wrote something along these lines, but I can't seem to find it right now...
--
1. Revisioning. The ability to use different patch levels or versions. The ability to see how much space these different versions are taking up. Hard drive space is cheap, and I'm amazed an enterprise customer hasn't demanded this yet from Red Hat.
rpm's --repackage feature appears to have this intention behind it. Unfortunately, it doesn't appear to work here as the GPG and MD5 signatures aren't redone.
2. Security Policy. RPMS and other package formats sometimes come with scripts to do necessary post-install stuff. It would be nice to have a seperate userspace library to handle the 'common' things that might be in these scripts like running ldconfig or mkfontdir. This way, it would be simple enough for the rpm tool to give you a rundown of what 'actions' needs to be done to install this application security-policy wise. Ideally most scripts would become superfluos and only used it really odd situations. And in those odd cases you can read through the script yourself.
RH have begun to do this with things like chkfontpath, chkconfig, so I think they're aware of it...
--
Red Hat 8.0 supports them out-of-the-box - Promise RAID controller, ALC650 sound, Intel Ethernet. Debian 3.0 doesn't seem to support the ethernet (it's on the CNR bus, apparently). Promise supply a binary module for the RAID controller, but there doesn't really seem to be any point - the hard bits are done in software anyway, so either use Linux ideraid or md and be done with it. I've gone with md, which also allows me to have mixed RAID0 and RAID1 devices using only 2 discs (not perfect resiliance, but good enough for my needs).
I threw a Celeron 1.7G in one machine and a P4 2.40B in the other.
The only thing I've found that doesn't appear to be terribly well supported is the environment sensor. I haven't tried the smartcard/memory card interface yet, nor the USB2.0 ports.
One thing to note is that the AGP slot is 4x, which limits you to 1.5volt cards - Geforce, Radeon, or Matrox, essentially.
--
Mine's dated 2002-08-06 and contains a /lot/ more (useful) information.
--
Tools->Options->Load/Save->Standard File Format->Always Save As.
--
Also nice for proxies and network daemons too.
--
Actually, I prefer ClearType on my Sony monitor, but not on my "regular" monitor at work.
I was going to write saying exactly the same thing. I've used Xft's sub-pixel (aka ClearType-alike) rendering on my laptop for some time now. When I got a 20" Sun monitor (Sony Trinitron tube), I thought "hey, I wonder how s-p rendering looks on this, given it has a rectangular RGB pattern?", not really expecting it to work. Somewhat to my surprise, it does work, arguably better than a TFT!
--
Every time you asked it a question, it would split into a number of entities, all of whom would reply "Bite me" simultaneously.
I've always defined AmigaDOS as dos.library, the shell commands and a few other bits and pieces, whilst AmigaOS includes AmigaDOS but also adds intuition, exec, Workbench and all the other standard bits.
--
In practice, it appears to be commonplace to be asked to sign a waiver of your employee rights when you apply to join a company. This happened to me and it (amongst a few other things) made me reject the company at that point.
I have willingly worked long/anti-social hours to help out in a crisis or special circumstances, but I refuse to work that way as a matter of course.
--
So, m > n, and m is the number of people to whom you give the secret, n is the number of people which will be required to reconstruct the secret.
That plane must be a hyper-plane, with n-1 dimensions.
n dimensions, by my reckoning (think of a 2-dimensional graph - you'll need two points to determine the line and therefore the point of interception).
What exactly is the secret? Point of interception with what?
Um, with a chosen axis where all but one of the variables=0. For example, with a 2-dimensional graph, you might choose the y-axis.
Read Eric's explanation above; he does a better job of it than me. Failing that, read Shamir's paper. ;-)
--
It's been over 7 years since I've done any worthwhile maths (e.g. anything more complicated than simultaneous equations) so I think I've got a legitimate excuse. ;-)
--
Google for "secret sharing" and you'll find plenty of references. Essentially, the secret (i.e. the password) is converted into a value that intercepts an axis of a n-dimensional graph. m points in n-dimensional space are then generated such that they lie in a straight line on a single plane. You can then distribute the values of the m points safe in the knowledge that you need at least n of them in order to calculate the point of interception of the secret.
AFAIK, this is how things like launch codes for nukes are stored and distributed (to counter the twin threats of elimination of keyholders preventing nukes from being launched, and to prevent a single rogue keyholder launching without appropriate authorisation).
Apologies to the maths/crypto purists out there if my description is fuzzy, over-simplified, or plain wrong, but it's been a while... ;-)
Better explanations can be found on RSA's site and in Ross Anderson's book "Security Engineering"
--
--
That'll all depend on the design of the modchip, the ease of installation and, by implication, how good a job you make of the installation.
Certainly, the intentions of modchip designers are to not impair normal functionality, but bugs creep in, some can be difficult to install (risking permanent damage to the host console) and later software releases can sometimes detect the presence of a modchip and refuse to run until it is removed or disabled.
Unless you have $200 to risk (and more importantly, the wrath of your spouse!) I'd wait until it was out of warranty or get a "professional" installation. Of course, given the grey legal area in which these devices reside, it's sometimes hard to tell the difference between a professional installer and a chimpanzee with a soldering iron. ;-]
--