Baloney. Don't blame the testers if they can't find all the bugs written by a poor programmer. It's the [good] programmer's job to test their own code first, as they have the most intimate knowledge of all the ways it could fail.
This is true... the drive could be reconditioned in the factory, but most end users won't have the equipment to do so.
I know drive companies have, in some cases, accepted photographs of the drive top stickers and serial numbers for warranty returns. The company signs a contract promising that these drives really are bad, and in exchange the drive vendor sends them a replacement. This works around the rules of many sensitive installations where no non-volatile storage can leave the premises without being completely destroyed.
Obviously the drive company knows the field failure rate of their products, so while you could game this for a few tens of drives, trying to get a few hundred for free wouldn't work unless you're already buying about half-a-million units. At those volumes, it's too much work for too little reward.
it must be around 512 kbps(remember, it's India I am talking about!) and must be a persistent connection, since we use source control softwares connecting to servers in the UK.
Have you actually measured how much bandwidth your source control software application consumes? To me that'd be the very first step, before you look into upgrading from one voodoo number to another. Real data is very often the key to good decisions.
I wonder how common it is for a user to have something like "1al02sk93dj8" written on a postit on their monitor, when in fact all they have to remember about their password is that the 'sk' in the middle is really a 'RD' making their real password "1a102RD93dj8"
This would (I imagine) wind up being significantly more secure to outside attacks (those who can't see the postit) while still being moderately secure to inside attacks (joe shmo trying to login on his console)....
Technically, he can relicense older GPL-licensed versions as well. However, that in no way revokes the GPL licensing on those same versions.
e.g. I release foo 1.0, and foo 1.1 under GPL, then decide to take my marbles home and release foo 1.2 under some proprietary license. That's legit, and I can even release 1.0 under that same proprietary license as well if I want to. However, the fact that 1.0 was already GPL'd means there's no way to un-GPL it.
If you've got a 300GB primary drive, it's foolish to use a 5GB drive for your swap. While you gain the benefit of having that drive separate from the primary (and potentially not contending for the bus), those drives are so far apart technology wise that you'd probably be better off with a swap partition on your most modern disk.
That 2/5/6GB drive may have a 20MB/s sequential rate at OD and half that at ID. Modern drives more than double that sequential performance (or triple), which is what's critical when swapping in/out a large job. Many drives in that generation don't support UDMA either, and talk with PIO, meaning you get no data checksum on your transfers.
You can span generations when you're using a cost reduced modern drive (fewer heads, same formats) but the drive that was stretching to make 5GB across 6/8 heads will be a real POS compared to modern drives performance wise.
Thrashing is bad, but thrashing to a slow disk I'd think would be worse. It is even compounded since that 5GB drive is probably PATA, meaning you're going to have your swap drive and primary drive sharing a cable, which will basically nuke most of the savings of 2 disks since they'll be reselecting master/slave at almost every command.
Using the new method, it is possible, for example, to produce two HTML documents with a long nonsense part after the closing </html>tag, which, despite slight differences in the HTML part, thanks to the adapted appendage have the same hash value.
So it appears that both the original and the new messages need that appendage. This isn't just about adding an appendage to a known, appendage-less document.
A very good idea IMO. Say your game burns 30KB/s of bandwidth per player... it'll take (by my weak math) about 9 hours to use 1GB of bandwidth, for which you paid $0.20... on average, that's gotta be at most an average daily usage. So effectively, your cost per user is in the $0.20/day range, or about $6/month for bandwidth.
Wonder what sort of latency these clusters have, if they'd be suitable to host a BF2 server or something.
I just sent myself the phone message, complete with all the personal details... and the time from website submission to phone call was about 1.2 seconds.
Whatever company put that together is pretty slick. Slight pauses around the names (would be interesting to see if you can get SLJ to say cusswords on your voicemail) but overall I'm impressed.
(Core) (Duo) = dual core, original core architecture, e.g. T2400-T2600 (Core) (Solo) = single core, original core architecture (Core 2) (Duo) = their new stuff, also dual core, e.g. E6200-E6600
One would therefore expect them to license from Gilette and call it Core 2 Quattro or something similar.
Most of what us "stuck in the past" folks hear about on Linux is development of new server applications or ways that IT can save money by deploying Linux, while simultaneously there are complaints about no "new" development on the platform... merely copying of existing Windows or Solaris or BSD functionality and applications.
My question, therefore, is do you believe this is an accurate representation of Linux development today? Do you believe that the standard user applications are an area that Linux should be developing towards, and what are you doing as Fedora project leader to influence this?
Thanks, and I'll take my answers off the air...
Re:That's an easy one.
on
IBM Opts for AMD
·
· Score: 2, Informative
Not all "blades" are single-socket implementations. Sun's flagship x86 blade is 4 sockets/8 cores using the Opteron 885, with up to 32GB of shared memory for those 4 sockets.
It would make sense for blades to appear in all sorts of configurations, depending on what application is being targeted and the available budget.
IANAL, but your machine is manipulating those bytes as they go by, and therefore you're tampering with their communications which may be legally protected.
As funny as this might be, I don't see it as being worth the potential liability. If the DMCA can attempt to outlaw drawing on your CD with a sharpie, then you could get in trouble for just about anything.
A replacement PCB would only work marginally with your drive, since each drive is run though the self-test and optimization process as a unit. The drive accounts for variations in manufacturing process (of every single part in the drive) at the time it is manufactured, and adjusts accordingly.
Your PCBA wouldn't sync with the HDA it was attached to, making reading and writing with the new drive unreliable.
If you send in the dead drive, they'll replace it with a functional one. That is how warranties work.
In colorado, due to the altitude, our gas (the same gas) has a lower octane rating, since changes in air pressure change the octane of the gas.
Our 85 octane is identical to California's 87 octane (or any other near-sea-level state), and our stations sell 85/87/91 for regular, plus, and premium unleaded gasolines.
If you drive through new mexico, you'll notice they sell 86/88/92, for the same reason...
CDROMs use constant data rate by varying the RPM of the drive depending on where you're located
hard drives have lower data rates at the inner diameter since they're spinning the same RPM all the time, so you simply get less linear distance to store data during the revolution
all of the sizes shipped to customers already account for this.
it would be possible to put more bits on the media by changing the speed that the disk rotates, but those loosened mechanical tolerances would give you a 4.7GB drive instead of a 300GB drive.
Blackjack is important, but I'd argue that 7-card stud poker is just as important. Everyone has 1 face up card at the beginning, and as people drop out, their visible cards disappear from the table.
Knowing what those cards were can be important at the end of the hand if you have anything other than a royal flush.
More importantly, there's quite a bit of history in introducing various spelling or other changes into a document, with unique modifications to each document that is distributed, in an attempt to identify a leak.
With the high volume, it's like it was run through a perl script to induce the errors before it was sent out, this way SCO can figure out who might be leaking sensitive information.
linux peeps use bitkeeper that has a bit more features suitable for large-scale development (out of the box distributed repos, changesets, etc). too bad bitkeeper's license is not suitable for commercial non-open source projects.
how is it not suitable? for non-open-source commercial products, you buy/lease your licenses, as you would with any other for-purchase tool.
you want free tools to develop commercial non-open-source software? Then yes, you'd have to look somewhere other than BitKeeper
--eric
Re:completely underwhelmed by Subversion...
on
Subversion 1.0 Released
·
· Score: 4, Informative
"The distributed tree model is also another problem. I'm sure that for Linux kernel development, arch makes sense. For a commercial product we do not want multiple trees. We want one consistent tree so when we go to a customer site we don't have to wonder why a circuit is malfunctioning because we didn't sync up with Jack's tree or whatever. We rejected BitKeeper on the same grounds; we weren't so much against paying but wanted something with the right feature set."
Just for the record, just because BitKeeper supports (and works great) in a fully distributed environment, doesn't mean you need to use it that way. Every developer can simply clone, then push each change back to the parent, and it would work like a centralized server.
If your developer "forgets" to push, that's no different in a distributed than a centralized system... once pushed, everyone has access to it.
There are other advantages to distributed operation too, mostly in failure tolerance and disconnected operation... BitKeeper is the only tool out there I am aware of that lets you work completely via floppy disks, without losing any functionality (it maintains its checksummed changeset model)
Slashdot Mirror
thanks for the link, Dunn better pucker up
Baloney. Don't blame the testers if they can't find all the bugs written by a poor programmer. It's the [good] programmer's job to test their own code first, as they have the most intimate knowledge of all the ways it could fail.
This is true... the drive could be reconditioned in the factory, but most end users won't have the equipment to do so.
I know drive companies have, in some cases, accepted photographs of the drive top stickers and serial numbers for warranty returns. The company signs a contract promising that these drives really are bad, and in exchange the drive vendor sends them a replacement. This works around the rules of many sensitive installations where no non-volatile storage can leave the premises without being completely destroyed.
Obviously the drive company knows the field failure rate of their products, so while you could game this for a few tens of drives, trying to get a few hundred for free wouldn't work unless you're already buying about half-a-million units. At those volumes, it's too much work for too little reward.
it must be around 512 kbps(remember, it's India I am talking about!) and must be a persistent connection, since we use source control softwares connecting to servers in the UK.
Have you actually measured how much bandwidth your source control software application consumes? To me that'd be the very first step, before you look into upgrading from one voodoo number to another. Real data is very often the key to good decisions.
I wonder how common it is for a user to have something like "1al02sk93dj8" written on a postit on their monitor, when in fact all they have to remember about their password is that the 'sk' in the middle is really a 'RD' making their real password "1a102RD93dj8"
This would (I imagine) wind up being significantly more secure to outside attacks (those who can't see the postit) while still being moderately secure to inside attacks (joe shmo trying to login on his console)....
thoughts?
Technically, he can relicense older GPL-licensed versions as well. However, that in no way revokes the GPL licensing on those same versions.
e.g. I release foo 1.0, and foo 1.1 under GPL, then decide to take my marbles home and release foo 1.2 under some proprietary license. That's legit, and I can even release 1.0 under that same proprietary license as well if I want to. However, the fact that 1.0 was already GPL'd means there's no way to un-GPL it.
If you've got a 300GB primary drive, it's foolish to use a 5GB drive for your swap. While you gain the benefit of having that drive separate from the primary (and potentially not contending for the bus), those drives are so far apart technology wise that you'd probably be better off with a swap partition on your most modern disk.
That 2/5/6GB drive may have a 20MB/s sequential rate at OD and half that at ID. Modern drives more than double that sequential performance (or triple), which is what's critical when swapping in/out a large job. Many drives in that generation don't support UDMA either, and talk with PIO, meaning you get no data checksum on your transfers.
You can span generations when you're using a cost reduced modern drive (fewer heads, same formats) but the drive that was stretching to make 5GB across 6/8 heads will be a real POS compared to modern drives performance wise.
Thrashing is bad, but thrashing to a slow disk I'd think would be worse. It is even compounded since that 5GB drive is probably PATA, meaning you're going to have your swap drive and primary drive sharing a cable, which will basically nuke most of the savings of 2 disks since they'll be reselecting master/slave at almost every command.
please define "easily" ... did you read the article?
From the article:
Using the new method, it is possible, for example, to produce two HTML documents with a long nonsense part after the closing </html>tag, which, despite slight differences in the HTML part, thanks to the adapted appendage have the same hash value.
So it appears that both the original and the new messages need that appendage. This isn't just about adding an appendage to a known, appendage-less document.Remember, interns are cheaper than actual solutions. That's actually a very good point. If I had mod points it'd be +1 insightful.
A very good idea IMO. Say your game burns 30KB/s of bandwidth per player... it'll take (by my weak math) about 9 hours to use 1GB of bandwidth, for which you paid $0.20... on average, that's gotta be at most an average daily usage. So effectively, your cost per user is in the $0.20/day range, or about $6/month for bandwidth.
Wonder what sort of latency these clusters have, if they'd be suitable to host a BF2 server or something.
I just sent myself the phone message, complete with all the personal details... and the time from website submission to phone call was about 1.2 seconds.
Whatever company put that together is pretty slick. Slight pauses around the names (would be interesting to see if you can get SLJ to say cusswords on your voicemail) but overall I'm impressed.
It would be Core 2 Quad or similar.
(Core) (Duo) = dual core, original core architecture, e.g. T2400-T2600
(Core) (Solo) = single core, original core architecture
(Core 2) (Duo) = their new stuff, also dual core, e.g. E6200-E6600
One would therefore expect them to license from Gilette and call it Core 2 Quattro or something similar.
Look at the email address of the submitter, it appears to be the owner of the server.
Guess he wanted to test the smoke alarm in his home office.
Most of what us "stuck in the past" folks hear about on Linux is development of new server applications or ways that IT can save money by deploying Linux, while simultaneously there are complaints about no "new" development on the platform... merely copying of existing Windows or Solaris or BSD functionality and applications.
My question, therefore, is do you believe this is an accurate representation of Linux development today? Do you believe that the standard user applications are an area that Linux should be developing towards, and what are you doing as Fedora project leader to influence this?
Thanks, and I'll take my answers off the air...
Not all "blades" are single-socket implementations. Sun's flagship x86 blade is 4 sockets/8 cores using the Opteron 885, with up to 32GB of shared memory for those 4 sockets.
It would make sense for blades to appear in all sorts of configurations, depending on what application is being targeted and the available budget.
IANAL, but your machine is manipulating those bytes as they go by, and therefore you're tampering with their communications which may be legally protected.
As funny as this might be, I don't see it as being worth the potential liability. If the DMCA can attempt to outlaw drawing on your CD with a sharpie, then you could get in trouble for just about anything.
orange is the next pink, didn't you hear?
A replacement PCB would only work marginally with your drive, since each drive is run though the self-test and optimization process as a unit. The drive accounts for variations in manufacturing process (of every single part in the drive) at the time it is manufactured, and adjusts accordingly.
Your PCBA wouldn't sync with the HDA it was attached to, making reading and writing with the new drive unreliable.
If you send in the dead drive, they'll replace it with a functional one. That is how warranties work.
actually, he means 85 octane.
In colorado, due to the altitude, our gas (the same gas) has a lower octane rating, since changes in air pressure change the octane of the gas.
Our 85 octane is identical to California's 87 octane (or any other near-sea-level state), and our stations sell 85/87/91 for regular, plus, and premium unleaded gasolines.
If you drive through new mexico, you'll notice they sell 86/88/92, for the same reason...
that is incorrect
CDROMs use constant data rate by varying the RPM of the drive depending on where you're located
hard drives have lower data rates at the inner diameter since they're spinning the same RPM all the time, so you simply get less linear distance to store data during the revolution
all of the sizes shipped to customers already account for this.
it would be possible to put more bits on the media by changing the speed that the disk rotates, but those loosened mechanical tolerances would give you a 4.7GB drive instead of a 300GB drive.
actually...
Blackjack is important, but I'd argue that 7-card stud poker is just as important. Everyone has 1 face up card at the beginning, and as people drop out, their visible cards disappear from the table.
Knowing what those cards were can be important at the end of the hand if you have anything other than a royal flush.
--eric
More importantly, there's quite a bit of history in introducing various spelling or other changes into a document, with unique modifications to each document that is distributed, in an attempt to identify a leak.
With the high volume, it's like it was run through a perl script to induce the errors before it was sent out, this way SCO can figure out who might be leaking sensitive information.
linux peeps use bitkeeper that has a bit more features suitable for large-scale development (out of the box distributed repos, changesets, etc). too bad bitkeeper's license is not suitable for commercial non-open source projects.
how is it not suitable? for non-open-source commercial products, you buy/lease your licenses, as you would with any other for-purchase tool.
you want free tools to develop commercial non-open-source software? Then yes, you'd have to look somewhere other than BitKeeper
--eric
"The distributed tree model is also another problem. I'm sure that for Linux kernel development, arch makes sense. For a commercial product we do not want multiple trees. We want one consistent tree so when we go to a customer site we don't have to wonder why a circuit is malfunctioning because we didn't sync up with Jack's tree or whatever. We rejected BitKeeper on the same grounds; we weren't so much against paying but wanted something with the right feature set."
Just for the record, just because BitKeeper supports (and works great) in a fully distributed environment, doesn't mean you need to use it that way. Every developer can simply clone, then push each change back to the parent, and it would work like a centralized server.
If your developer "forgets" to push, that's no different in a distributed than a centralized system... once pushed, everyone has access to it.
There are other advantages to distributed operation too, mostly in failure tolerance and disconnected operation... BitKeeper is the only tool out there I am aware of that lets you work completely via floppy disks, without losing any functionality (it maintains its checksummed changeset model)
--eric