ha! what a conspiracy theory! don't forget about the black helicopters! you'd better put some tin foil on your head, to stop the mind control rays!
first of all, from a security stand-point, do you believe for a second that online voting is a good idea? do you have any idea what could happen if such a system were compromised?!?! you talk of corruption of the democratic system, yet avocate what would cause more corruption! online voting should be outlawed. anyone with any common sense knows it's bad idea.
second, i don't want more people to vote, i want LESS! do you really want more uninformed people voting? (if they were informed, they'd already be voting.) there are way too many stupid voters out there and you want more! ignorance is destroying america, and you apparently want more of it.
To connect a shell to the serial port: take out the drive, mount it under linux (use bswap to do byte swapping). To mount it under linux, you probably have to recompile your kernel using the genhd.c from the tivo linux sources. Anyway, once you mount it you'll find several things on several partitions. You can then edit the startup rc.d's to put a shell on/dev/ttyS3 and then you can use a null modem cable to connect to that shell while it's back in the Tivo unit. Pretty neat.
tivo uses big-endian ext2? if so, i believe fsck still has the meta-data byte swap option. doesn't bswap swap every byte on the partition?
first of all, there's no such thing as a 128bit risc cpu. and by 128bit i mean either 128bit wide interger registers and/or 128bit vm addresses. both x86 and ppc chips are 32bit.
also, all recent macs have internal ide interfaces NOT scsi.
thirdly, afaik, the g4s are not export controlled AT ALL. the export rules where updated a few years ago, iirc.
no, cisc instructions are broken down into simpler ops by the microcode. cisc is the same as it's always been. yes, modern cisc chips have similar designs as risc chips, but that doesn't make cisc any more risc; it's just cuz they're modern designs.
why all the hype around ia-64? imnsho, it's just another overly complex arch from intel. also, there are already alpha systems available to test code on (eg, compaq's test drive program), for 64bit cleanliness(sp).
what the world needs is not another overly complicated arch. if you want to go the VLIW way, sun's majc is much cleaner (though, you really need to use java).
alpha, sparc, mips, and ppc are already better designed and are availiable now. intel's brand name and their $$$ are the only reasons ia-64 may survive.
before i reply to this, i want to make it know that i use linux and have some BSD experience, and i'm not biased either way.
Thier license makes it easy for them to fragment should vendors decide to start improving it.
that's funny considering that everyone and their brother has their own rpm based dist. the bsds are MUCH more organized than the various linux dists. linux is the one that's in serious danger of fragmenting. for some strange reason, everyone wants their own dist. it's just stupid and it's massive duplication of effort.
debian, redhat, and slackware are all the linux i'll ever need (forked arch specific dists not withstanding; eg, since redhat themselves don't support ppc, there's nothing wrong with the ppc (rpm based) reference release).
that's not true. for example, if you traceroute an erols dialup, you'll see the 10. for the ppp server, and no that doesn't break the rfc. iirc, the rule is you can route from 10., etc but not from (eg, icmp from a 10. is ok, but if you try to telnet to a 10. it shouldn't go past your local border).
DEC failed because they over-engineered. The Alphas were head and shoulders above i386, but nobody used them. Why? Because DEC kept "improving" them. They also acted like "if you build it they will come".
over engineered? that's a misuse of the term. also, i think you don't have any idea what you're talking about. if alpha is such a failure, why didn't compaq can it when they bought dec?
just cuz all you've ever seen are architecturally obsolete x86s, doesn't mean that's what the whole world uses. ever hear of a little thing called vms? also, alphas are big in sciencetific areas. So intead of trying to perfect the ARM--why not work on getting some market share first?
1. MS should go after individual posters. they own copyright to whatever they post, as per slashdot's terms.
2. a lot of people need to grow up and quick this "fight the power" "down with the Man" crap. would you like it if ms violated your copyright license (eg, the gpl)? do you know what "double standard" means?
now, as far as whether or not those posters violated ms's license (btw, you don't violate a copyright, you violate a LICENSE), is another story. i have one question: some posters claimed that each page had a copy of the license; is this true? (i have not looked, so that i'm not contaminated by their trade secret).
if it's true, then you're fucked. if the only place the terms were displayed was by executing the self-extracting archive, and you used winzip or whatever to bypass that, then you should be in the clear.
slashdot should point out the fact that posters own copyright to their own posts, and that slashdot is not responsible for the content. that being true, you should not remove the posts unless ordered to by a court, else risk the responsibility to have to check every single post.
The convention is that when a processor is labeled an "xx-bit CPU", the xx is referrring to size of the address space not the size of its data types or data paths. These days, most general purpose CPUs (16-bit, 32-bit, and 64-bit) all support the standard set of integer and FP types which range up to 64 bits in length.
wrong. cpus' bit-width refers to the width of the general purpose (interger) registers. some modern 32bit cpus, such as some pentium cores, and the latest g4 revision, support 36bit addressing. that doesn't make them 36bit cpus. also, x86 fpu registers are really 80bits wide.
So far, I don't think I've seen any general purpose processors with hardware support for 128-bit data types, mainly because there isn't really a demand for it. However, 128-bit types are sometimes supported on special purpose hardware for certain applications that need the extra precision.
wrong, again. altivec, alpha mvi, and other simd instruction sets uses 128bit vectors.
Well, I'll certainly admit that e2fs is fragile in power loss. Way more then FAT, or FAT32 even, in my experience. But I don't really see what that has to do with a server's over all stability. If the power goes out, its still going to stop responding:P
the fragility has nothing to do with the fs and everything to do with fs caching. fat and fat32 are primitive fses on primitive oses (windows) that have no write caching. that added reliability (which log based fses have, as well) is not worth the large performance hit.
sorensen, fwih, requiers 2d hardware accell, which xanim doesn't support. also, it isn't apple's to give away. they're licensing it from someone else. intel also has their own closed codecs (i263, etc), despite their influx of $$$ into the linux world.
If the rights have to be signed over to the FSF for the license to be enforcable, why doesn't someone who has already downloaded it sign them over before Mattel stops them too. I'm no lawyer, but it sounds ok to me. Anybody?
no, it's NOT ok. you do not own the copyright. there seems to be some serious misconceptions about copyright law. the GPL is license for use, modification, and redistrobution. it does NOT assign the copyright to anyone. i think 99% of the posters here need to go buy a book on copyright law.
just saying in a comment in some.c file that it's "GPL'd" is a very, very bad idea. you must include a copy of the licensing(sp) agreement, otherwise, (and ianal) the license may be void, since the licensee never saw the terms. this is why you put the "if you didn't get a copy..." line in GPL'd stuff, so that there's no question about whether or not the license is valid!
just saying "yeah, yeah, it's GPL'd" is seriously asking for trouble.
also, take a look at my configure.in and makefile.in for wipe. i always found most of the configure.ins that i could get my hands on, to be confusing. mine's not too complicated, so maybe it'll help you. i found autoconf confusing at first, as well.
not only is it closed source, for some bizarre reason, but they only compiled it for x86 linux! it does no good on the at least tens of thousands of non x86 linux boxes (and bsd). these feds really have no idea what they're doing.
even if a closed dvd player WAS licenesed(sp), it'd most likely be useless for anything but x86. this is one of the problems with closed source products "for linux": they're not really for linux, they're for linux/x86. i wish people writing articles such as this, would point that out. that is, that it's a big reason why closed source software is not an acceptible solution.
anyway, other than my nitpicking there, that's a great article.
first of all, i'd like to whine about hemos not mentioning that it's only available for x86.
secondly, i went to the opera site and the future supported archs list has "G3/G4" listed. this is just nitpicking, but if you compile something to run on a "G3/G4" it'll run on any ppc, so i don't know why they list it as "G3/G4".
are you on crack? redhat's initscripts are the worst i've ever seen. when i switched from redhat to debian, it was the best choice i've ever made! rh initscripts have been buggy in every version i've ever used. debian is SO much nicer.
why should gun buyers be forced to buy trigger locks? many people keep their guns in safes, so why would they need one? and don't forget that nothing prevents a person from throwing the trigger lock away, or just leaving the key in it. now, if you want to pass a law that says guns must be secured in some fassion when not in use, that's another issue.
one example, you ask? how bout this: initscripts. redhat initscript have been nothing but a pain from 4.2 to 5.2 (the last version i used). i was always fixing obvious bugs in rh's initscripts. contrast this w/ debian. i have had to fix only one bug (an extra $ in an initscript). also, debian has update-rc.d, which makes life SO much better (i think redhat also has an initscript symlink manager, though). also, 99% of all the debs out there are in the dist, so i can just apt-get install them. there's no central repository for rpms (though las.978.org is a big help).
I'm not aware of any case law which forces Real to produce player software for each and every architecture of each and every Operating system out there. This is much the same.
eh? i never said they should be forced to write software. what i'm saying is, if they DID write a "linux version", it would almost certainly be only for x86 (and maybe ppc) linux, leaving everyone else screwed.
Slashdot Mirror
ha! what a conspiracy theory! don't forget about the black helicopters! you'd better put some tin foil on your head, to stop the mind control rays!
first of all, from a security stand-point, do you believe for a second that online voting is a good idea? do you have any idea what could happen if such a system were compromised?!?! you talk of corruption of the democratic system, yet avocate what would cause more corruption! online voting should be outlawed. anyone with any common sense knows it's bad idea.
second, i don't want more people to vote, i want LESS! do you really want more uninformed people voting? (if they were informed, they'd already be voting.) there are way too many stupid voters out there and you want more! ignorance is destroying america, and you apparently want more of it.
tivo uses big-endian ext2? if so, i believe fsck still has the meta-data byte swap option. doesn't bswap swap every byte on the partition?
first of all, there's no such thing as a 128bit risc cpu. and by 128bit i mean either 128bit wide interger registers and/or 128bit vm addresses. both x86 and ppc chips are 32bit.
also, all recent macs have internal ide interfaces NOT scsi.
thirdly, afaik, the g4s are not export controlled AT ALL. the export rules where updated a few years ago, iirc.
and, as per usual, the extra 4bits are yet another hack upon the hopelessly out of date x86 isa.
no, it IS the cpu arch, but yes, it's also the pc arch. eg, pc bios.
no, cisc instructions are broken down into simpler ops by the microcode. cisc is the same as it's always been. yes, modern cisc chips have similar designs as risc chips, but that doesn't make cisc any more risc; it's just cuz they're modern designs.
why all the hype around ia-64? imnsho, it's just another overly complex arch from intel. also, there are already alpha systems available to test code on (eg, compaq's test drive program), for 64bit cleanliness(sp).
what the world needs is not another overly complicated arch. if you want to go the VLIW way, sun's majc is much cleaner (though, you really need to use java).
alpha, sparc, mips, and ppc are already better designed and are availiable now. intel's brand name and their $$$ are the only reasons ia-64 may survive.
it's mach with a bsd syscall interface. the userland is bsd, though.
Thier
license makes it easy for them to fragment should vendors decide to start improving it.
that's funny considering that everyone and their brother has their own rpm based dist. the bsds are MUCH more organized than the various linux dists. linux is the one that's in serious danger of fragmenting. for some strange reason, everyone wants their own dist. it's just stupid and it's massive duplication of effort.
debian, redhat, and slackware are all the linux i'll ever need (forked arch specific dists not withstanding; eg, since redhat themselves don't support ppc, there's nothing wrong with the ppc (rpm based) reference release).
that's not true. for example, if you traceroute an erols dialup, you'll see the 10. for the ppp server, and no that doesn't break the rfc. iirc, the rule is you can route from 10., etc but not from (eg, icmp from a 10. is ok, but if you try to telnet to a 10. it shouldn't go past your local border).
over engineered? that's a misuse of the term. also, i think you don't have any idea what you're talking about. if alpha is such a failure, why didn't compaq can it when they bought dec?
just cuz all you've ever seen are architecturally obsolete x86s, doesn't mean that's what the whole world uses. ever hear of a little thing called vms? also, alphas are big in sciencetific areas. So intead of trying to perfect the ARM--why not work on getting some market share first?
better products increase market share.
1. MS should go after individual posters. they own copyright to whatever they post, as per slashdot's terms.
2. a lot of people need to grow up and quick this "fight the power" "down with the Man" crap. would you like it if ms violated your copyright license (eg, the gpl)? do you know what "double standard" means?
now, as far as whether or not those posters violated ms's license (btw, you don't violate a copyright, you violate a LICENSE), is another story. i have one question: some posters claimed that each page had a copy of the license; is this true? (i have not looked, so that i'm not contaminated by their trade secret).
if it's true, then you're fucked. if the only place the terms were displayed was by executing the self-extracting archive, and you used winzip or whatever to bypass that, then you should be in the clear.
slashdot should point out the fact that posters own copyright to their own posts, and that slashdot is not responsible for the content. that being true, you should not remove the posts unless ordered to by a court, else risk the responsibility to have to check every single post.
btw, IANAL
wrong. cpus' bit-width refers to the width of the general purpose (interger) registers. some modern 32bit cpus, such as some pentium cores, and the latest g4 revision, support 36bit addressing. that doesn't make them 36bit cpus. also, x86 fpu registers are really 80bits wide.
So far, I don't think I've seen any general purpose processors with hardware support for 128-bit data types, mainly because there isn't really a demand for it. However, 128-bit types are sometimes supported on special purpose hardware for certain applications that need the extra precision.
wrong, again. altivec, alpha mvi, and other simd instruction sets uses 128bit vectors.
the fragility has nothing to do with the fs and everything to do with fs caching. fat and fat32 are primitive fses on primitive oses (windows) that have no write caching. that added reliability (which log based fses have, as well) is not worth the large performance hit.
sorensen, fwih, requiers 2d hardware accell, which xanim doesn't support. also, it isn't apple's to give away. they're licensing it from someone else. intel also has their own closed codecs (i263, etc), despite their influx of $$$ into the linux world.
has already downloaded it sign them over before Mattel stops them too. I'm no lawyer, but it sounds ok to
me. Anybody?
no, it's NOT ok. you do not own the copyright. there seems to be some serious misconceptions about copyright law. the GPL is license for use, modification, and redistrobution. it does NOT assign the copyright to anyone. i think 99% of the posters here need to go buy a book on copyright law.
just saying in a comment in some .c file that it's "GPL'd" is a very, very bad idea. you must include a copy of the licensing(sp) agreement, otherwise, (and ianal) the license may be void, since the licensee never saw the terms. this is why you put the "if you didn't get a copy..." line in GPL'd stuff, so that there's no question about whether or not the license is valid!
just saying "yeah, yeah, it's GPL'd" is seriously asking for trouble.
also, take a look at my configure.in and makefile.in for wipe. i always found most of the configure.ins that i could get my hands on, to be confusing. mine's not too complicated, so maybe it'll help you. i found autoconf confusing at first, as well.
not only is it closed source, for some bizarre reason, but they only compiled it for x86 linux! it does no good on the at least tens of thousands of non x86 linux boxes (and bsd). these feds really have no idea what they're doing.
even if a closed dvd player WAS licenesed(sp), it'd most likely be useless for anything but x86. this is one of the problems with closed source products "for linux": they're not really for linux, they're for linux/x86. i wish people writing articles such as this, would point that out. that is, that it's a big reason why closed source software is not an acceptible solution.
anyway, other than my nitpicking there, that's a great article.
first of all, i'd like to whine about hemos not mentioning that it's only available for x86.
secondly, i went to the opera site and the future supported archs list has "G3/G4" listed. this is just nitpicking, but if you compile something to run on a "G3/G4" it'll run on any ppc, so i don't know why they list it as "G3/G4".
are you on crack? redhat's initscripts are the worst i've ever seen. when i switched from redhat to debian, it was the best choice i've ever made! rh initscripts have been buggy in every version i've ever used. debian is SO much nicer.
why should gun buyers be forced to buy trigger locks? many people keep their guns in safes, so why would they need one? and don't forget that nothing prevents a person from throwing the trigger lock away, or just leaving the key in it. now, if you want to pass a law that says guns must be secured in some fassion when not in use, that's another issue.
one example, you ask? how bout this: initscripts. redhat initscript have been nothing but a pain from 4.2 to 5.2 (the last version i used). i was always fixing obvious bugs in rh's initscripts. contrast this w/ debian. i have had to fix only one bug (an extra $ in an initscript). also, debian has update-rc.d, which makes life SO much better (i think redhat also has an initscript symlink manager, though). also, 99% of all the debs out there are in the dist, so i can just apt-get install them. there's no central repository for rpms (though las.978.org is a big help).
I'm not aware of any case law which forces Real to produce player software for each and every
architecture of each and every Operating system out there. This is much the same.
eh? i never said they should be forced to write software. what i'm saying is, if they DID write a "linux version", it would almost certainly be only for x86 (and maybe ppc) linux, leaving everyone else screwed.