If that is the case, does that mean that if I lose my copy of the physical media I purchased, or if it gets scratched and becomes unplayable, that I am immediately entitled to a new copy of the media, because I purchased an irrevocable "right to view" license?
The studios, for their part, say no.
So, is it truly the media or the "right to view" that you are purchasing? The studios can't have it both ways, and have not offered us an answer to this question in no uncertain terms yet.
It took me awhile, but I finally managed to get a mirror of the site up. Hopefully this should ease the Slashdot effect. It will be up unless the author asks me to remove it.
What the hell are you talking about? Transactions and row-level locking are *absolutely* needed for high availability and performance. Without transactions, there's no way to ensure that your data is really there on disk (MySQL has no such guarantees, which makes it nearly impossible to do replication). Without row-level locking, you cannot have a high concurrent insert/update rate, because all pending commits are forced to block.
Recently Nullsoft switched from MySQL to Oracle for precisely this reason, and the Shoutcast directory insert/select performance was estimated at a tenfold increase. My company is making the same move in short order.
It's not, as you claim, a hardware issue. FreeBSD on i386 supports files > 4GB without any problems whatsoever.
Intel hardware has other issues, but this isn't one of them. This is an OS issue.
Re:Tough to find jobs months ahead of time.
on
Finding a Linux Job
·
· Score: 1
Relax. There will still be plenty of jobs when you get out of school, unless, the Internet isn't popular anymore and we enter a recession, neither of which looks likely at this point.
Mr. Garfinkel is correct in stating that Linux is susceptible to virii. Almost every operating system is.
A better treatment of the subject, however, would have been an analysis of the types of "risky behaviour" (to coin a phrase often used in the 1980s, and I do realise it's a cheesy term!) that could lead to the viral epidemic he envisions. As Linux increases in popularity, a greater number of people will engage in risky behaviour, solely out of ignorance, because they, like most computer users, are unaware of the ways that computer virii are contracted and spread.
Viral infections on UNIX platforms are generally less frequent than infections on other platforms because software for UNIX platforms has traditionally been available in source format. In the not-so-distant past, there was a One True Location where one could download the source code for a particular project, and one could assume with a reasonable degree of certainty that if one did a "ftp/get; configure && make && make install" that the software would be installed as described with few surprises.
But, the world is changing. The "download, examine, compile, install" days are disappearing fast. Mirror sites for source tarballs, often untrusted, appear more frequently these days, and binary RPMs are being built and distributed to servers around the globe by anonymous or obscure third parties.
We must consider the growing commercial appeal of Linux and the increasing number of binary-only software packages being shipped daily. It's far easier to contract a virus in a pirated binary copy of, say, Oracle 8.x (as an example) and installed as root (because the instructions said you should do so) than it would be if you installed the latest Sendmail build that you downloaded from Sendmail Inc. and compiled on your own box.
What all this means is that while Mr. Garfinkel is correct, and there is certainly an untapped market for anti-virus software, one should take care not to overhype the threat and to examine the ways that virii can be introduced, particularly through the proliferation of closed-source software and the implicit trust many people mistakenly give it.
I'm glad more people are beginning to realize that headless operation capability is a great asset to people who have to manage UNIX systems, and that having hardware support for such management is critical. Most UNIX systems vendors (such as Sun) have had this for years now.
However, my first impression of this card is "too little, too late."
First, as an earlier poster pointed out, it's ISA only, not PCI (and server-class motherboards supporting ISA are quickly becoming extinct).
Second, look at that card! It's frigging huge! It looks more like a FPGA prototype; I'm sure the designers could have it converted to a single chip ASIC and make the card 75% smaller.
Third, the last thing many of us who are maintaining machines with 1 or 2 rack unit heights is another card to try to fit in there. Some of us would like to use what little room we have for things like Gigabit Ethernet cards.
Finally, I'm not sure there will be much need for this in a few months. Award (now Phoenix) has a gorgeous ServerBIOS (which Intel is using on all of its new server motherboards) which supports serial console support. We're using one of their motherboards in all our new systems (I believe that VA Linux Systems uses them too) and we think they kick ass.
However, even serial console support isn't perfect. After all, how do you send the three-finger salute over a serial line?
My issue with the article begins with the third paragraph:
The number of package management systems is very large, and it is neither possible nor desirable to standardize on a single one.
Why is it neither possible nor desirable to standardize on a single package management system? I have been extremely happy with RPM as a basis for package management. It's vendor-neutral, architecture-neutral, compresses nicely, provides for both source and binary package types, and provides for building from pristine sources. What could possibly be wrong with that?
I get the feeling that what he's shooting for here is a way to create a single specification file to be used with a tool to create binary packages for all architectures, and all package managers. In this way I could theoretically build a Linux RPM, a Linux DEB, a Solaris pkg, and a FreeBSD whatever-the-hell-package-format-they-use-when-not -using-the-ports-collection.
My point of view is, "why bother?" It seems to me that implementing RPM (or a similar format, perhaps with extensions to handle dependencies like DEB does) is the logical way to go here. One spec file can already create packages for multiple targets.
As an aside, I believe this paper is a perfect example of a demonstration of how as a community, we seem to suffer from multiple-personality syndrome when it comes to our software and tools. Do we let the various options duke it out in the "marketplace"?, or do we standardize for interoperability and easy configuration management? Both have their merits, but I chose RPM at my workplace because I think at this point it's the "best of breed" when it comes to package management and software distribution, and if I had to choose a package management system for every OS, RPM would be it.
My suggestion is that you get a Palm III (which can be obtained VERY cheaply--CNet Shopper reports that you can get one for as little as $175 new), and download and register a nifty little program called OmniRemote, which can be located at http://www.pacificneotek.com/omnisw.htm .
My experience with OmniRemote is wonderful. It really does work well, and it costs a fraction of that of a Take Control remote (buying which, I might add, generously contributes to Microsoft's coffers).
What relevance is there whether Google caches your pages or not? If you choose to make your Web page public, everyone should have equal ability to view your site. Any other behaviour is tantamount to censorship.
Furthermore, Google is not rebroadcasting or retransmitting anyone's content; that is, Google does not modify anyone's pages or re-package them. Google only provides a historical record, and I don't think there's anything wrong with that. Besides, relative links are converted to absolute links; following links in a cached page will send the browser to the owner's URL, not to Google's cached version of it.
If you don't want your content to be archived, don't post it publicly. Don't post to mailing lists or to USENET either, because your content will be archived on various list archive services and Deja.com (among various other news service sites) as well.
I've found that you can get great deals for used mixers on eBay. I'm certain you can find what you're looking for for well under $200 if you're patient.
While I completely agree with the above reference, I disagree that qmail belongs in the same class as Sidewinder or any Microsoft product. qmail is an open-source program--therefore it can be audited in an open-box fashion as Mr. Spafford claims is best.
I'm not certain what the big deal is about the price of retrieving a copy of TiVo's source modifications. All it takes is a single person to pay Tivo for its expenses in shipping out those changes. Then that single person is more than welcome to post those changes to the Web for all of us to examine. In fact, that person is more than welcome to an account on my machine, which has plenty of bandwidth for the downloading.
Endgame: TiVo regains its time, and we get the code. Everyone happy? Good.
It's not entirely clear whether the extensions to MP3 make files using the extensions unplayable on ordinary MP3 players
The SDK is (sigh) only available on Windows platforms
Satellite dish comments
on
Saving MST3K
·
· Score: 1
I have a DBS system at home (DirecTV/USSB, Sony A3 unit) and I love it to pieces! The programming selection is excellent for the price, installation was cake (took me about an hour in my apartment), and the picture and sound quality are to die for (use the S-Video input for maximum effect).
Oh yeah, and the translucent on-screen menu and the fact that I get to watch old new wave videos on M2 is pretty damn cool too.:-)
Slashdot Mirror
Dial 1-800-CALL-SPY. Seriously. I'm not kidding. It's a voice mail box you can use to report such things.
If that is the case, does that mean that if I lose my copy of the physical media I purchased, or if it gets scratched and becomes unplayable, that I am immediately entitled to a new copy of the media, because I purchased an irrevocable "right to view" license?
The studios, for their part, say no.
So, is it truly the media or the "right to view" that you are purchasing? The studios can't have it both ways, and have not offered us an answer to this question in no uncertain terms yet.
It took me awhile, but I finally managed to get a mirror of the site up. Hopefully this should ease the Slashdot effect. It will be up unless the author asks me to remove it.
The URL is http://www.dynamine .net/mirrors/innominate.org/projects/tuning/
The server is on a 100Mb Exodus link, running FreeBSD 4.0. Have fun!
What the hell are you talking about? Transactions and row-level locking are *absolutely* needed for high availability and performance. Without transactions, there's no way to ensure that your data is really there on disk (MySQL has no such guarantees, which makes it nearly impossible to do replication). Without row-level locking, you cannot have a high concurrent insert/update rate, because all pending commits are forced to block.
Recently Nullsoft switched from MySQL to Oracle for precisely this reason, and the Shoutcast directory insert/select performance was estimated at a tenfold increase. My company is making the same move in short order.
It's not, as you claim, a hardware issue. FreeBSD on i386 supports files > 4GB without any problems whatsoever.
Intel hardware has other issues, but this isn't one of them. This is an OS issue.
Relax. There will still be plenty of jobs when you get out of school, unless, the Internet isn't popular anymore and we enter a recession, neither of which looks likely at this point.
Mr. Garfinkel is correct in stating that Linux is susceptible to virii. Almost every operating system is.
/get; configure && make && make install" that the software would be installed as described with few surprises.
A better treatment of the subject, however, would have been an analysis of the types of "risky behaviour" (to coin a phrase often used in the 1980s, and I do realise it's a cheesy term!) that could lead to the viral epidemic he envisions. As Linux increases in popularity, a greater number of people will engage in risky behaviour, solely out of ignorance, because they, like most computer users, are unaware of the ways that computer virii are contracted and spread.
Viral infections on UNIX platforms are generally less frequent than infections on other platforms because software for UNIX platforms has traditionally been available in source format. In the not-so-distant past, there was a One True Location where one could download the source code for a particular project, and one could assume with a reasonable degree of certainty that if one did a "ftp
But, the world is changing. The "download, examine, compile, install" days are disappearing fast. Mirror sites for source tarballs, often untrusted, appear more frequently these days, and binary RPMs are being built and distributed to servers around the globe by anonymous or obscure third parties.
We must consider the growing commercial appeal of Linux and the increasing number of binary-only software packages being shipped daily. It's far easier to contract a virus in a pirated binary copy of, say, Oracle 8.x (as an example) and installed as root (because the instructions said you should do so) than it would be if you installed the latest Sendmail build that you downloaded from Sendmail Inc. and compiled on your own box.
What all this means is that while Mr. Garfinkel is correct, and there is certainly an untapped market for anti-virus software, one should take care not to overhype the threat and to examine the ways that virii can be introduced, particularly through the proliferation of closed-source software and the implicit trust many people mistakenly give it.
I'm glad more people are beginning to realize that headless operation capability is a great asset to people who have to manage UNIX systems, and that having hardware support for such management is critical. Most UNIX systems vendors (such as Sun) have had this for years now.
However, my first impression of this card is "too little, too late."
First, as an earlier poster pointed out, it's ISA only, not PCI (and server-class motherboards supporting ISA are quickly becoming extinct).
Second, look at that card! It's frigging huge! It looks more like a FPGA prototype; I'm sure the designers could have it converted to a single chip ASIC and make the card 75% smaller.
Third, the last thing many of us who are maintaining machines with 1 or 2 rack unit heights is another card to try to fit in there. Some of us would like to use what little room we have for things like Gigabit Ethernet cards.
Finally, I'm not sure there will be much need for this in a few months. Award (now Phoenix) has a gorgeous ServerBIOS (which Intel is using on all of its new server motherboards) which supports serial console support. We're using one of their motherboards in all our new systems (I believe that VA Linux Systems uses them too) and we think they kick ass.
However, even serial console support isn't perfect. After all, how do you send the three-finger salute over a serial line?
I hate to burst your bubble, but the DMCA was an Act passed by both houses of Congress, then sent to President Clinton, who signed it.
The enactment of the DMCA was not, therefore, an act of the sole discretion of the executive branch of the Government.
My issue with the article begins with the third paragraph:
t -using-the-ports-collection.
The number of package management systems is very large, and it is neither possible nor desirable to standardize on a single one.
Why is it neither possible nor desirable to standardize on a single package management system? I have been extremely happy with RPM as a basis for package management. It's vendor-neutral, architecture-neutral, compresses nicely, provides for both source and binary package types, and provides for building from pristine sources. What could possibly be wrong with that?
I get the feeling that what he's shooting for here is a way to create a single specification file to be used with a tool to create binary packages for all architectures, and all package managers. In this way I could theoretically build a Linux RPM, a Linux DEB, a Solaris pkg, and a FreeBSD whatever-the-hell-package-format-they-use-when-no
My point of view is, "why bother?" It seems to me that implementing RPM (or a similar format, perhaps with extensions to handle dependencies like DEB does) is the logical way to go here. One spec file can already create packages for multiple targets.
As an aside, I believe this paper is a perfect example of a demonstration of how as a community, we seem to suffer from multiple-personality syndrome when it comes to our software and tools. Do we let the various options duke it out in the "marketplace"?, or do we standardize for interoperability and easy configuration management? Both have their merits, but I chose RPM at my workplace because I think at this point it's the "best of breed" when it comes to package management and software distribution, and if I had to choose a package management system for every OS, RPM would be it.
Even better: Use ISO 8601 timestamps for the version numbers.
199806011754 = 5:54 pm, 1 June 1998
200001010000 = midnight, 1 January 2000
--Michael
My suggestion is that you get a Palm III (which can be obtained VERY cheaply--CNet Shopper reports that you can get one for as little as $175 new), and download and register a nifty little program called OmniRemote, which can be located at http://www.pacificneotek.com/omnisw.htm .
My experience with OmniRemote is wonderful. It really does work well, and it costs a fraction of that of a Take Control remote (buying which, I might add, generously contributes to Microsoft's coffers).
I know the DOJ's site is going to be Slashdotted, so I've set up another mirror:
/ms-findings.pdf
http://www.dynamine.net/microsoft
I disagree with your argument.
What relevance is there whether Google caches your pages or not? If you choose to make your Web page public, everyone should have equal ability to view your site. Any other behaviour is tantamount to censorship.
Furthermore, Google is not rebroadcasting or retransmitting anyone's content; that is, Google does not modify anyone's pages or re-package them. Google only provides a historical record, and I don't think there's anything wrong with that. Besides, relative links are converted to absolute links; following links in a cached page will send the browser to the owner's URL, not to Google's cached version of it.
If you don't want your content to be archived, don't post it publicly. Don't post to mailing lists or to USENET either, because your content will be archived on various list archive services and Deja.com (among various other news service sites) as well.
I've found that you can get great deals for used mixers on eBay. I'm certain you can find what you're looking for for well under $200 if you're patient.
While I completely agree with the above reference, I disagree that qmail belongs in the same class as Sidewinder or any Microsoft product. qmail is an open-source program--therefore it can be audited in an open-box fashion as Mr. Spafford claims is best.
Just wanted to clarify.
I'm not certain what the big deal is about the price of retrieving a copy of TiVo's source modifications. All it takes is a single person to pay Tivo for its expenses in shipping out those changes. Then that single person is more than welcome to post those changes to the Web for all of us to examine. In fact, that person is more than welcome to an account on my machine, which has plenty of bandwidth for the downloading.
Endgame: TiVo regains its time, and we get the code. Everyone happy? Good.
Here's a URL containing the info-sheet on the technology the new Rio purports to use:
http://www.intertrust.com/prod ucts/mp3plussheet.html
Some points of note:
I have a DBS system at home (DirecTV/USSB, Sony A3 unit) and I love it to pieces! The programming selection is excellent for the price, installation was cake (took me about an hour in my apartment), and the picture and sound quality are to die for (use the S-Video input for maximum effect).
:-)
Oh yeah, and the translucent on-screen menu and the fact that I get to watch old new wave videos on M2 is pretty damn cool too.