Many of the software/practices/etc. for a team are very different depending on what they're doing, and there's no sense of that in the question. For teams of spread out developers working together, you need strong version control and issue tracking software. Teams doing support will need ways to collaborate on a shared knowledgebase. The right software is very dependent on the job.
The only general thing all projects like this need is good communications software. You're going to want simple text chat sometimes, shared multi-party voice calls others, and small video conferences others. Skype is the only thing I've found that does a reasonable job on all of these things at once. I now have calls linking people in 7 countries with chat and/or audio. You can do better for each specific requirement with other software though.
Also, you really need to get as many team members as possible together at least once a year. You can blow through all sorts of unproductive things people have been hung up in a single good dinner with your co-workers.
No they didn't, read the white paper about it. You can see all the capacitors involved in the anandtech review even. In theory, this has finally fixed the problem that made Intel's drive unusable for high-performance databases, that the write cache was useless in that context because it lied about writes.
With even the "do no evil" Google doing major tax evasion, is anyone surprised an old boy's club like GM is doing even fancier tricks? I'm at the point now where I don't even consider companies that are net tax neutral to be that bad. You have to actively be siphoning money away from the taxpayers via bailouts and unprosecuted financial fraud to register on my radar nowadays.
If I were going to live my live and set my goals based on what the average person thinks is reasonable, I'd be reading about this week's episode of "American Idol" instead of browsing here on Slashdot. The point you're missing is that people should be able to pry into whatever level of detail they feel like on the things they own. My ability to tinker with my microwave is limited only by my electronics skills, but some types of software hacks can land you in jail. That should bother you.
And Stallman wrote about some other reasons why software is different ten years ago using a car analogy. One reason he works on software is because it's possible to replicate it infinitely for little cost. Even if I wanted to tinker with my microwave, without some tools that cost more than a PC I couldn't really do so, and others couldn't easily adopt any improvements I made. Focusing on software gives you more leverage to really do something that impacts the world, relative to your investment, than any other type of technical work.
Wait, did you connect your computer to the network using a regular cable when you did the conversion? There's your problem. You need to use a good network cable or the bits aren't polished properly when you convert from MP3 to FLAC. You might think "but I didn't even use the network when I was converting". Doesn't matter--the audio bits leak out of there if you're not using the right cable.
Why not "Chasing Replicants", "The Affair of the Replicants", or "Replicants Lost & Found". Or maybe we could get one about the son of the eye maker killed in the first movie, as he runs around seeking revenge by removing the eyes his father made. That would of course be "The Blind Replicants".
The only surprise is that they're talking about new material inspired by Blade Runner, rather than planning a "even more gritty reboot!" of the original movie.
K. W. Jeter published two attempts at writing a sequel to Blade Runner, inspired by the movie rather than PKD's original novel. The Edge of Human and Replicant Night waver along the edge between mediocre and horrifying throughout. I have little hope for a movie to do better.
I use XFS mainly on production database servers, where it has been a significant improvement over any of the other Linux filesystem alternatives. I agree that it's not appropriate for small memory systems, which is one reason why it's only caught on again recently I think. I really don't care though; I don't own a system with less than 2GB of RAM now, and even the most trivial server I use has 8GB of RAM.
Re:Why use FreeBSD when you can use Linux?
on
FreeBSD 8.2 Released
·
· Score: 3, Interesting
I'll bite. The main reasons I consider using FreeBSD nowadays are:
1) Reasonable filesystem support. ext3 and ext4 are just terrible filesystem for 24x7 production systems. The potential for long fsck times alone is enough to remove them from a lot of serious applications. XFS does better, but with its lack of popularity the user base is a little scary. Meanwhile, FreeBSD has ZFS, which is just a better filesystem that almost any other choice. And it also has UFS2, which avoids the whole "let's keep the server down while we do a long filesystem check sometimes" problem Linux suffers with by doing background fsck.
2) The new FreeBSD 8.2 includes userland DTrace support, which has been the missing piece that has kept earlier verisons from replacing Solaris for me on a lot of systems. systemtap on Linux just completely misses the point from a complexity and "scary" perspective. It just doesn't have that feel that you're not going to hurt the running process by using it that DTrace has always managed.
The subject of how many bits and what sampling rate is sufficient for playback was beaten to death in 1997. Check out Bob Stuart's article "Coding High Quality Digital Audio", PDF at Meridian white papers.
The issue is not just your hearing. You have to consider how the most common forms of distortion in real-world equipment will mess with things, issues like quantization/dithering deviation from perfection and phase issues interfering with high frequency playback. Attacking those two from a combined theory/measured practice standpoint, Bob's numbers say if you reach a full 20 bits and 58KHz of resolution, that will be effectively perfect even given the typical errors in digital playback. Obviously you have to record at better than that to have some margin for error as sound is processed and mixed, but that's as far as can be easily justified on the home playback side.
Given the current state of the loudness war, this is all kind of moot for newer recordings. But I own about a dozen higher than CD quality releases on DVD, DVD-A, and SACD, all from analog tape transfers, that are so much better than their respective CDs that anyone who listens seriously would never confuse them.
Yes's 90125 is just not a good sounding CD. I have about half a dozen different versions of it in that format--US remasters, Japanese remasters, Gold CD--and not a one of them sounds good. Love the music, hate the engineering. If you want a Yes CD that sounds good, try the recent Mobile Fidelity remaster of The Yes Album. It's fairly expensive, but it's shockingly good. Never expected that old album to ever sound that nice.
Unfortunately even when higher fidelity formats came out, the same crappy mastering issues were still around. Sticking with Yes, they released Fragile as a DVD-Audio title. It sounds terrible; exaggerated treble, sibilance, just an awful sounding release. Sony did the same thing with SACD, plenty of those remasters don't sound better than good quality transfers onto CD did. Proper mastering is more important than bit rate. But if you get the combination of good engineering, mastering, and a higher than CD quality release, some of those can sound really amazing.
The unfortunate part about that test is that they're using two fundamentally broken pieces in the "High End system". So it's both unsurprising that there was actually a regression from the cheaper stuff, and not necessarily representative of what more expensive equipment is capable of.
The "Terminator" part of the MIT Terminator speaker cables is a simple Zobel network, a cheap resistor/capacitor pair (really cheap in the case of the Terminator 3, the parts quality is terrible). That's essentially a tone control of seriously questionable value, where you have no idea how it's going to interact with the amplifier and speaker impedance. Those MIT cables measure worse and, to my ears, sound worse than cheap copper cable does.
Second, YBA power amplifiers are some of the worst scams on the market. The designer rejects negative feedback a a near religious level, so you end up with high distortion, badly changing performance based on amplifier thermals, poor ability to drive low impedance loads, and amplifiers that blow up; it's all in the review if you read that part instead of the ill-founded subjective spew. I would take a nice solid Behringer A500 any day over one of YBA's pieces of junk.
The school of high-end audio I fall into says that first, the equipment must measure extremely well. Only after passing that hurdle is it then meaningful to consider whether it sounds better or worse than another component that also measures well. That's not what happened here. This Matrix Hi-Fi test started with fundamentally, measurably flawed equipment on the "high-end" side. It's no surprise it didn't do well against the less expensive but competently engineered cheap stuff. Bravo to the testers who rejected the overpriced junk here. But you can't really extrapolate too far into the high-end audio industry from that though. It's actually hard to setup a good test in this area. So few audiophiles know enough to filter their shopping list to only includes equipment with good measurements on the electronics side that any random system you borrow for such a test can easily be crap regardless of price.
Re:Is the GIL removed from the interpreter
on
Python 3.2 Released
·
· Score: 1
The whole beauty of Python was the idea of Duck typing, that if you pass the wrong type into a function, sooner or later, python will complain and make your mistake obvious.
Usually later, after the program has been deployed when it works on all expected data. Then it can trip a type exception and crash the first time it runs into something unexpected, which is always fun for the user. Duck typing had enough perils because of that, so the fact that there is are even more things postponed to runtime checks that can work unexpectedly is not a happy thing. Thanks for pointing this issue out.
I feel like Python 3.0 is suffering from some serious Second-system effect issues. All I keep finding when I consider migrating some work toward it is stuff that is more complicated and prone to breaking in new ways, without any compelling improvements that make that worth the trouble.
Re:Is the GIL removed from the interpreter
on
Python 3.2 Released
·
· Score: 1
It is unfortunate your post has not been moderated upward to where it deserves to be, "+5 titties".
Re:Is the GIL removed from the interpreter
on
Python 3.2 Released
·
· Score: 3, Informative
Yes, it would be great if an update to this were covered in the article, like if they put notes on changes to the GIL right here or something.
Only rare Tivo models with Tivo Basic features, and original Series 1 Tivos, are capable of recording without guide data. If you have the most common type of Series 2 or 3 Tivo, and there is no guide data, you cannot manually record anything. The device is effectively useless, and "bricked" is quite appropriate to describe the resulting worthless box.
As for using alternate sources of data, that exact subject--running a Tivo without service--has always been the line the Tivo hacking community didn't publicly cross. I've hacked in as root on my older Tivo and installed a web server and other goodies on it. That was easy; swapping the guide data out, that's really hard.
Clickable link. The summary of that publicly available benchmark was that just turning off the normal data integrity features in PostgreSQL, specifically its aggressive use of the fsync system call, was enough to make PostgreSQL run as about as fast or faster as any of the popular NoSQL approaches. Some of the NoSQL alternatives had significantly lower data loading times however. But as a whole, only MongoDB really had any significant performance gain, everything else was hard pressed to keep up with boring old Postgres when comparing fairly--MongoDB certainly doesn't use fsync for example.
There are some intermediate steps between "no integrity" and "full transactional integrity" available in PostgreSQL as well, so you can adjust how much you're willing to pay per commit on a per transaction basis. Combine this with the fact that a key-value store with good performance is available, and you can get most of what NoSQL promises with it when that's appropriate, while still having full database features available when you need those too.
As alluded to in the intro, the book tries to cover PostgreSQL versions from 8.1 though 9.0, with a long listing of what has changed between each version to help you figure out what material does and doesn't apply. So most of the advice applies even if you're running an older version. There is also a companion volume to this one of sorts also available, PostgreSQL 9 Admin Cookbook, that was written at the same time and coordinated such that there's little overlap between the two titles. That one focuses more on common day to day administration challenges, less on the theory.
Lives with his brother in Manhattan, so presumably single. If you live someplace as nice as a NYC apartment, go ahead and cast those stores. Used to live there myself, and everybody I know who has a nice place there doesn't say LOL; not placing my bet on you so far.
Slashdot Mirror
Many of the software/practices/etc. for a team are very different depending on what they're doing, and there's no sense of that in the question. For teams of spread out developers working together, you need strong version control and issue tracking software. Teams doing support will need ways to collaborate on a shared knowledgebase. The right software is very dependent on the job.
The only general thing all projects like this need is good communications software. You're going to want simple text chat sometimes, shared multi-party voice calls others, and small video conferences others. Skype is the only thing I've found that does a reasonable job on all of these things at once. I now have calls linking people in 7 countries with chat and/or audio. You can do better for each specific requirement with other software though.
Also, you really need to get as many team members as possible together at least once a year. You can blow through all sorts of unproductive things people have been hung up in a single good dinner with your co-workers.
Some decent to great arcades I've been to recently that are filled with classic games, in order of decreasing awesomeness:
They're still out there.
No they didn't, read the white paper about it. You can see all the capacitors involved in the anandtech review even. In theory, this has finally fixed the problem that made Intel's drive unusable for high-performance databases, that the write cache was useless in that context because it lied about writes.
With even the "do no evil" Google doing major tax evasion, is anyone surprised an old boy's club like GM is doing even fancier tricks? I'm at the point now where I don't even consider companies that are net tax neutral to be that bad. You have to actively be siphoning money away from the taxpayers via bailouts and unprosecuted financial fraud to register on my radar nowadays.
If I were going to live my live and set my goals based on what the average person thinks is reasonable, I'd be reading about this week's episode of "American Idol" instead of browsing here on Slashdot. The point you're missing is that people should be able to pry into whatever level of detail they feel like on the things they own. My ability to tinker with my microwave is limited only by my electronics skills, but some types of software hacks can land you in jail. That should bother you.
And Stallman wrote about some other reasons why software is different ten years ago using a car analogy. One reason he works on software is because it's possible to replicate it infinitely for little cost. Even if I wanted to tinker with my microwave, without some tools that cost more than a PC I couldn't really do so, and others couldn't easily adopt any improvements I made. Focusing on software gives you more leverage to really do something that impacts the world, relative to your investment, than any other type of technical work.
Wait, did you connect your computer to the network using a regular cable when you did the conversion? There's your problem. You need to use a good network cable or the bits aren't polished properly when you convert from MP3 to FLAC. You might think "but I didn't even use the network when I was converting". Doesn't matter--the audio bits leak out of there if you're not using the right cable.
Why not "Chasing Replicants", "The Affair of the Replicants", or "Replicants Lost & Found". Or maybe we could get one about the son of the eye maker killed in the first movie, as he runs around seeking revenge by removing the eyes his father made. That would of course be "The Blind Replicants".
The only surprise is that they're talking about new material inspired by Blade Runner, rather than planning a "even more gritty reboot!" of the original movie.
K. W. Jeter published two attempts at writing a sequel to Blade Runner, inspired by the movie rather than PKD's original novel. The Edge of Human and Replicant Night waver along the edge between mediocre and horrifying throughout. I have little hope for a movie to do better.
I use XFS mainly on production database servers, where it has been a significant improvement over any of the other Linux filesystem alternatives. I agree that it's not appropriate for small memory systems, which is one reason why it's only caught on again recently I think. I really don't care though; I don't own a system with less than 2GB of RAM now, and even the most trivial server I use has 8GB of RAM.
I'll bite. The main reasons I consider using FreeBSD nowadays are:
1) Reasonable filesystem support. ext3 and ext4 are just terrible filesystem for 24x7 production systems. The potential for long fsck times alone is enough to remove them from a lot of serious applications. XFS does better, but with its lack of popularity the user base is a little scary. Meanwhile, FreeBSD has ZFS, which is just a better filesystem that almost any other choice. And it also has UFS2, which avoids the whole "let's keep the server down while we do a long filesystem check sometimes" problem Linux suffers with by doing background fsck.
2) The new FreeBSD 8.2 includes userland DTrace support, which has been the missing piece that has kept earlier verisons from replacing Solaris for me on a lot of systems. systemtap on Linux just completely misses the point from a complexity and "scary" perspective. It just doesn't have that feel that you're not going to hurt the running process by using it that DTrace has always managed.
The subject of how many bits and what sampling rate is sufficient for playback was beaten to death in 1997. Check out Bob Stuart's article "Coding High Quality Digital Audio", PDF at Meridian white papers.
The issue is not just your hearing. You have to consider how the most common forms of distortion in real-world equipment will mess with things, issues like quantization/dithering deviation from perfection and phase issues interfering with high frequency playback. Attacking those two from a combined theory/measured practice standpoint, Bob's numbers say if you reach a full 20 bits and 58KHz of resolution, that will be effectively perfect even given the typical errors in digital playback. Obviously you have to record at better than that to have some margin for error as sound is processed and mixed, but that's as far as can be easily justified on the home playback side.
Given the current state of the loudness war, this is all kind of moot for newer recordings. But I own about a dozen higher than CD quality releases on DVD, DVD-A, and SACD, all from analog tape transfers, that are so much better than their respective CDs that anyone who listens seriously would never confuse them.
Yes's 90125 is just not a good sounding CD. I have about half a dozen different versions of it in that format--US remasters, Japanese remasters, Gold CD--and not a one of them sounds good. Love the music, hate the engineering. If you want a Yes CD that sounds good, try the recent Mobile Fidelity remaster of The Yes Album. It's fairly expensive, but it's shockingly good. Never expected that old album to ever sound that nice.
Unfortunately even when higher fidelity formats came out, the same crappy mastering issues were still around. Sticking with Yes, they released Fragile as a DVD-Audio title. It sounds terrible; exaggerated treble, sibilance, just an awful sounding release. Sony did the same thing with SACD, plenty of those remasters don't sound better than good quality transfers onto CD did. Proper mastering is more important than bit rate. But if you get the combination of good engineering, mastering, and a higher than CD quality release, some of those can sound really amazing.
The unfortunate part about that test is that they're using two fundamentally broken pieces in the "High End system". So it's both unsurprising that there was actually a regression from the cheaper stuff, and not necessarily representative of what more expensive equipment is capable of.
The "Terminator" part of the MIT Terminator speaker cables is a simple Zobel network, a cheap resistor/capacitor pair (really cheap in the case of the Terminator 3, the parts quality is terrible). That's essentially a tone control of seriously questionable value, where you have no idea how it's going to interact with the amplifier and speaker impedance. Those MIT cables measure worse and, to my ears, sound worse than cheap copper cable does.
Second, YBA power amplifiers are some of the worst scams on the market. The designer rejects negative feedback a a near religious level, so you end up with high distortion, badly changing performance based on amplifier thermals, poor ability to drive low impedance loads, and amplifiers that blow up; it's all in the review if you read that part instead of the ill-founded subjective spew. I would take a nice solid Behringer A500 any day over one of YBA's pieces of junk.
The school of high-end audio I fall into says that first, the equipment must measure extremely well. Only after passing that hurdle is it then meaningful to consider whether it sounds better or worse than another component that also measures well. That's not what happened here. This Matrix Hi-Fi test started with fundamentally, measurably flawed equipment on the "high-end" side. It's no surprise it didn't do well against the less expensive but competently engineered cheap stuff. Bravo to the testers who rejected the overpriced junk here. But you can't really extrapolate too far into the high-end audio industry from that though. It's actually hard to setup a good test in this area. So few audiophiles know enough to filter their shopping list to only includes equipment with good measurements on the electronics side that any random system you borrow for such a test can easily be crap regardless of price.
The whole beauty of Python was the idea of Duck typing, that if you pass the wrong type into a function, sooner or later, python will complain and make your mistake obvious.
Usually later, after the program has been deployed when it works on all expected data. Then it can trip a type exception and crash the first time it runs into something unexpected, which is always fun for the user. Duck typing had enough perils because of that, so the fact that there is are even more things postponed to runtime checks that can work unexpectedly is not a happy thing. Thanks for pointing this issue out.
I feel like Python 3.0 is suffering from some serious Second-system effect issues. All I keep finding when I consider migrating some work toward it is stuff that is more complicated and prone to breaking in new ways, without any compelling improvements that make that worth the trouble.
It is unfortunate your post has not been moderated upward to where it deserves to be, "+5 titties".
Yes, it would be great if an update to this were covered in the article, like if they put notes on changes to the GIL right here or something.
Only rare Tivo models with Tivo Basic features, and original Series 1 Tivos, are capable of recording without guide data. If you have the most common type of Series 2 or 3 Tivo, and there is no guide data, you cannot manually record anything. The device is effectively useless, and "bricked" is quite appropriate to describe the resulting worthless box.
As for using alternate sources of data, that exact subject--running a Tivo without service--has always been the line the Tivo hacking community didn't publicly cross. I've hacked in as root on my older Tivo and installed a web server and other goodies on it. That was easy; swapping the guide data out, that's really hard.
The National Federation of the Blind sued Target for a $6M settlement because their site was not accessible to blind users.
Official pronounciation recording. Postgres-Q-L. "Postgres" is also fine.
Well, Slashdot does store their information in a MySQL database...
Clickable link. The summary of that publicly available benchmark was that just turning off the normal data integrity features in PostgreSQL, specifically its aggressive use of the fsync system call, was enough to make PostgreSQL run as about as fast or faster as any of the popular NoSQL approaches. Some of the NoSQL alternatives had significantly lower data loading times however. But as a whole, only MongoDB really had any significant performance gain, everything else was hard pressed to keep up with boring old Postgres when comparing fairly--MongoDB certainly doesn't use fsync for example.
There are some intermediate steps between "no integrity" and "full transactional integrity" available in PostgreSQL as well, so you can adjust how much you're willing to pay per commit on a per transaction basis. Combine this with the fact that a key-value store with good performance is available, and you can get most of what NoSQL promises with it when that's appropriate, while still having full database features available when you need those too.
Thanks to Joshua for the nice review here. There are actually a few more samples from the book than just the one chapter; here's a full list of them:
In addition to this one and the customer reviews at Amazon, there have been two other reviews by notable PostgreSQL contributors: Buy this book, now and PostgreSQL 9 High Performance Book Review.
As alluded to in the intro, the book tries to cover PostgreSQL versions from 8.1 though 9.0, with a long listing of what has changed between each version to help you figure out what material does and doesn't apply. So most of the advice applies even if you're running an older version. There is also a companion volume to this one of sorts also available, PostgreSQL 9 Admin Cookbook, that was written at the same time and coordinated such that there's little overlap between the two titles. That one focuses more on common day to day administration challenges, less on the theory.
There's also Hinting at PostgreSQL, by the author of the book being reviewed here (me), covering what hinting mechanism are available. And finally Why the F&#% Doesn't Postgres Have Hints?!?! suggesting why some feel that still isn't enough.
Lives with his brother in Manhattan, so presumably single. If you live someplace as nice as a NYC apartment, go ahead and cast those stores. Used to live there myself, and everybody I know who has a nice place there doesn't say LOL; not placing my bet on you so far.