I currently burn CD-Rs of all of my music to
put in my CD changer in my car. This is due to the fact that I get higher density that way (I can fill those CD-Rs up to 74 minutes vs. the 45-55 minutes that are on a typical CD. And yes, I know about 80min CDs, but the firmware in my car's CD changer gets confused by them). This is also due to the fact that my car tends to damage the CDs over time (long radial gashes along the CD when I hit a bump, combined with the extreme heat of Texas summers). By putting my music on CDRs, I protect my original investment. As an added bonus, I can bring along just the tracks I'm interested in. Anti-circumvention policies applied to new media would restrict my ability to make these lawful copies.
Eventually, I plan to get an MP3/Ogg Vorbis player installed in my car. (Probably when I get my next car.) By the time I get it, the music industry is likely to have a favorite new digital music format with some sort of access control. Meanwhile, I'm going to be trying to put all of my music into my car in Ogg Vorbis format where possible, to provide the highest possible quality with the least likelihood of getting sued by Fraunhaufer. I won't be able to do that legally, though, if the new music formats have some sort of "encryption" ("XOR 64" anyone?) on them.
On a side note, the DMCA's anti-circumvention clause almost guarantees weak "encryption" and "protection" measures by exchanging technology for
laws. Fun.
And now for a fun odd-ball question:
Is the pattern of light-movement created by a graphic equalizer or other visualization method (eg. the visualizations that various car stereos and such provide) considered a "derivative work"?
Huh? 30GB? Linux 2.2.16 (which is the kernel tarball I had handy) is ~70MB uncompressed, and that includes all of the source, documentation and drivers.
The core kernel is pretty small. It only
looks big when you take all of the drivers and other bits into account, most of which are not used on a given platform. For instance, the stuff under arch/s390 is only needed if you're building for a mainframe.
I don't see what POSIX capabilities has to do
with this. Perhaps you can enlighten me?
Back to the discussion at hand:
I can set MAX_TASKS_PER_USER and MIN_TASKS_LEFT_FOR_ROOT in linux/tasks.h. I can also limit the maximum memory usage of any given task with the ulimit mechanism you mention. (I can do that as root from getty or login before the
user has a chance to do anything.)
Both of those mechanisms would work towards preventing a mortal-user fork-bomb from trashing
the machine. (A "max total memory per user" would be nice, but I would think the way modern UNIX VM's work make such an idea rather difficult to pin down, in practice.)
What I understand capabilities to be (referring to POSIX capabilities here) is just fine-grained access to the abilities that normally only root has. I don't see how that prevents a fork-bomb
from happening (although I suppose I do see how this prevents a fork-bomb from happening accidentally as root).
As some have noted, it's because they're a known quantity. That's important. Also, as some of my friends at work point out, the older process technologies are more robust in environments like space, since you need more electrons to flip transistors and the like. As you get to smaller and smaller geometries, radiation-induced errors become more prevalent, and so it's harder to prevent them or compensate for them.
Sure, you can shield the components and whatnot, but at some point you reach practical limits. (Bear in mind that the shielding also needs to dissipate heat, etc....)
Dude, read the article. The problem is that
the solar arrays raise the potential of the entire space station relative to the thin plasma bath that's around it. In other words,
the space station is like a live wire at ~120V and space is the ground. It doesn't matter where you're at, if you're doing EVA, you're the lightning rod.
Good question. What's really sad here is that
SVID, POSIX, and BSD all probably do state that these sorts of non-ANSI APIs are supposed to show up in string.h (or maybe even strings.h !!) as part of their interface definition. Ick. To change that now would be tantamount to changing these standards. (Not that that would necessarily be bad, but then you'd have another set of not-quite-compatible standards to try to be compatible with.)
One way to adapt your code in a semi-portable (or at least in a somewhat self-documenting) fashion is to #define _POSIX_SOURCE and #define _SVID_SOURCE (or _BSD_SOURCE depending on your
code) explicitly to enable some of these features even in the presence of -ansi. By explicitly defining these in your code (say, in a configuration header), you effectively state to the human reading the source that you rely on non-ANSI APIs being exported in these otherwise standard headers.
The unfortunate mess that we've inherited has all of these non-standard APIs spewn across all of these standard headers. It's for that reason that tools like GNU autoconf exist. I'd rather these APIs all be confined to their own headers as you suggest. *sigh*
At any rate, if you have your resource limits cranked up for some reason, or a privileged process develops a bug and goes ape-shit, well then...:-) As the poster a couple levels up said, the reason the one machine needed a reboot was because some in-house application did exactly that.
Me, clueless about C? I think not.
Email me sometime and we can compare notes.
I could give a sh*t if this discussion were about Linux. The compiler's behavior was correct, and
I'm sorry, but you were just simply wrong.
Of course that works -- you have a prototype for flockOfMeese in scope. When you
use the -ansi switch on GCC, the compiler defines the macro __STRICT_ANSI__, which causes the prototype for strdup to be excluded from string.h. This can be overridden by an application by explicitly enabling various non-ANSI featuresets by defining one of the following macros: __USE_SVID, __USE_BSD, __USE_XOPEN_EXTENDED.
Each of these macros enables one of several non-ANSI API sets to be visible from the standard headers as a portability aid for other platforms which (unwisely) chose to export their APIs within the ANSI C headers. In an ideal world, these other interfaces would be exported in their own platform-specific headers.
Just because your example works under FreeBSD doesn't mean it's right. FreeBSD happens to allow some of the BSD-specific APIs to leak through the standard headers, even with -ansi on the compiler command line. Ideally, the ANSI-specified headers would only define the ANSI-specified APIs (particularly in the case of supplying -ansi -pedantic to the compiler).
And, BTW, this isn't just about Linux. I've run into the "strdup isn't part of ANSI C"
problem on plenty of platforms, including Macintosh and on DSPs. In your example, the compiler was doing its job: It informed you that you were calling an API that was not defined in any of the headers you included, and since you were including only ANSI C compliant headers (made compliant by -ansi), you can then fix your program. Why else have compiler diagnostics?
If anything, this says the FreeBSD headers are sloppy.
Furthermore, their adoption of VHS over the superior Betamax was because VHS was _cheaper_. The reason people originally bought these VHS tapes was because there was very litle else to buy.
legitimate companies imagined video to be a threat to their business. That wouldnt have been a factor for porn producers at the time (and now, for that matter) because "Fat Moe and his credit card"
isnt exactly a business situation where the concerned parties need to sit on the facts pending further study.
No, Sony wouldn't allow adult content on Betamax, plain and simple. I'm sure had Sony not placed any such restrictions on Betamax, the format would've thrived for much, much longer.
strdup is not specified by ANSI C. You need to compile without -ansi in order to see strdup, so the first warning is your own damn fault. Lack of a warning in this case should be considered a bug.
Second, I don't get the same second warning as you do. Rather, I get a secondary warning related to strdup not having a prototype in scope. Again, if you compile without -ansi the warning goes away.
In short, it's your own damn fault for using -ansi while trying to use an API entry that's not part of ANSI C's standard library.
I disagree. An application that starts thrashing the machine sometimes can only be brought under control via a reboot. Imagine if a privileged process starts the equivalent of
while (1) { char *c=malloc(1); *c = 0; fork(); }
I
don't care what OS you have, the easiest way to
reign that one is is to reboot. Things get even worse if said task is allocating other resources along the way (such as file descriptors, network sockets, what-have-you).
I also want to hear Sony's SACD: like 2.4Mhz sampling rate, but 1 bit.
The bitrate is only 50% higher than a CD's bitrate (1.5Mbit/sec), so don't go creaming in your pants
just yet.
The main difference the 1 bit/sample makes in this
case is that your bandwidth theoretically stretches to a much higher (and quite ridiculous)
1.2MHz. Of course, the SNR is really, really
low at 1.2MHz. For such a system, the effective
dynamic range (and SNR) is inversely proportional
to the frequency. You'll gain high-end range at
the expense of high-end precision and range. Assuming they use something like sigma-delta demodulation to decode this into listenable audio, you also lose
dynamic range over most of the listening band due to the concept of "slope overload".
(ObDisclaimer: That is, if I remember my signal processing courses from school correctly. I may program DSPs for a living, but that's because I'm a good coder, not because I was good with DSP theory. Most of what I do is other engineering, not actual signal processing.)
Yup, which is why every few months I show up
to work with signs plastered over the walls and
on all of the entrances saying "Do not open attachments named whatever.exe". Currently
we have signs saying "navidad.exe" that went up
a couple days ago.
Also, depending on the nature of the virus, they will also disable the dial-in modem pools, turn all the file servers to read only, and damn near
send everyone home for the day. Meanwhile, I'm
sitting there, reading mail in mutt on my Solaris box wondering what all the commotion is about.
It's sorta like a business-model patent. You could take the oldest profession, rephrase it
in terms of a "method", and strap on "involving
a computer" and/or "network", and voila! Get
yourself a patent.
I don't see a noun form of affect in my Webster's. (Specifically, "Webster's II New Riverside Dictionary, Revised Edition.") Granted, it's not quite as comprehensive as, say, the Oxford English Dictionary, but it does do a pretty good job of covering the portion of the language people actually still use.;-)
You liked the flashbacks? I prefer
flashbacks that actually flash back to scenes
rather than introducing new material. Sorta like
your English teacher tells you: Never introduce new information in a conclusion. These flashbacks tend to conclude various subplots, yet they introduce new information. Urgl!
Basically, I enjoyed the movie as a "don't think
to hard, sit back and enjoy the special FX"
sort of movie, and that was about it. There
was some bad science, the occasional correct
science (such as the fire extinguisher in zero-G),
and a fair amount of action. Not too bad.
But, it was definitely one of those movies that,
as you get more distant from it, you realize how
empty it was. Like a firework after it's been
lit, the flash is gone, the wow is
gone, and you're left with just so much hollow
shell.
That said, the movie was worth it, but only
because we got in with discount tickets so it
was $3.00 a head instead of $7.00. W/out the
discount tickets, I'd say wait for it to come
out on VHS/DVD/Beta/Whatever and rent it
from Ballbuster or something.
I had a similar problem (root perms) when I
installed one of the NS6 preview releases. It
appears the installer honors your umask setting, and that ends up removing permission
bits all throughout the install dirs. Not too
bright, I guess.
The fix was to find and make all the files in the
install dir globally readable, and files w/ the
X bit executable. Something along the lines of:
Depending on which version of Linux you're running,
you could be running into threading bugs in Linux's libc. I found that upgrading my libc on my RH6.0 box to the same libc that's in RH6.2 made a bit of difference for Netscape (and Mozilla's) stability.
It showed more for Mozilla.
Is it showing 135MB for the RSS or the SIZE on
xmms and kdeinit?
If the RSS is that big, then top is confused.
If the SIZE is that big, then perhaps one or
both applications is (a) memory mapping some
devices (sound card, perhaps) and that mapping
is being counted towards the process, or (b)
one or both is leaking / allocating large
amounts of memory but never faulting it in.
Memory that's allocated but never faulted in
won't show up in RAM or in swap.
Slashdot Mirror
I currently burn CD-Rs of all of my music to put in my CD changer in my car. This is due to the fact that I get higher density that way (I can fill those CD-Rs up to 74 minutes vs. the 45-55 minutes that are on a typical CD. And yes, I know about 80min CDs, but the firmware in my car's CD changer gets confused by them). This is also due to the fact that my car tends to damage the CDs over time (long radial gashes along the CD when I hit a bump, combined with the extreme heat of Texas summers). By putting my music on CDRs, I protect my original investment. As an added bonus, I can bring along just the tracks I'm interested in. Anti-circumvention policies applied to new media would restrict my ability to make these lawful copies.
Eventually, I plan to get an MP3/Ogg Vorbis player installed in my car. (Probably when I get my next car.) By the time I get it, the music industry is likely to have a favorite new digital music format with some sort of access control. Meanwhile, I'm going to be trying to put all of my music into my car in Ogg Vorbis format where possible, to provide the highest possible quality with the least likelihood of getting sued by Fraunhaufer. I won't be able to do that legally, though, if the new music formats have some sort of "encryption" ("XOR 64" anyone?) on them.
On a side note, the DMCA's anti-circumvention clause almost guarantees weak "encryption" and "protection" measures by exchanging technology for laws. Fun.
And now for a fun odd-ball question: Is the pattern of light-movement created by a graphic equalizer or other visualization method (eg. the visualizations that various car stereos and such provide) considered a "derivative work"?
--Joe--
Program Intellivision!
Huh? 30GB? Linux 2.2.16 (which is the kernel tarball I had handy) is ~70MB uncompressed, and that includes all of the source, documentation and drivers.
The core kernel is pretty small. It only looks big when you take all of the drivers and other bits into account, most of which are not used on a given platform. For instance, the stuff under arch/s390 is only needed if you're building for a mainframe.
--Joe--
Program Intellivision!
I don't see what POSIX capabilities has to do with this. Perhaps you can enlighten me?
Back to the discussion at hand: I can set MAX_TASKS_PER_USER and MIN_TASKS_LEFT_FOR_ROOT in linux/tasks.h. I can also limit the maximum memory usage of any given task with the ulimit mechanism you mention. (I can do that as root from getty or login before the user has a chance to do anything.) Both of those mechanisms would work towards preventing a mortal-user fork-bomb from trashing the machine. (A "max total memory per user" would be nice, but I would think the way modern UNIX VM's work make such an idea rather difficult to pin down, in practice.)
What I understand capabilities to be (referring to POSIX capabilities here) is just fine-grained access to the abilities that normally only root has. I don't see how that prevents a fork-bomb from happening (although I suppose I do see how this prevents a fork-bomb from happening accidentally as root).
So what am I not understanding?
--Joe (Genuinely interested)--
Program Intellivision!
As some have noted, it's because they're a known quantity. That's important. Also, as some of my friends at work point out, the older process technologies are more robust in environments like space, since you need more electrons to flip transistors and the like. As you get to smaller and smaller geometries, radiation-induced errors become more prevalent, and so it's harder to prevent them or compensate for them.
Sure, you can shield the components and whatnot, but at some point you reach practical limits. (Bear in mind that the shielding also needs to dissipate heat, etc....)
--Joe--
Program Intellivision!
Dude, read the article. The problem is that the solar arrays raise the potential of the entire space station relative to the thin plasma bath that's around it. In other words, the space station is like a live wire at ~120V and space is the ground. It doesn't matter where you're at, if you're doing EVA, you're the lightning rod.
That's BAD.
--Joe--
Program Intellivision!
Good question. What's really sad here is that SVID, POSIX, and BSD all probably do state that these sorts of non-ANSI APIs are supposed to show up in string.h (or maybe even strings.h !!) as part of their interface definition. Ick. To change that now would be tantamount to changing these standards. (Not that that would necessarily be bad, but then you'd have another set of not-quite-compatible standards to try to be compatible with.)
One way to adapt your code in a semi-portable (or at least in a somewhat self-documenting) fashion is to #define _POSIX_SOURCE and #define _SVID_SOURCE (or _BSD_SOURCE depending on your code) explicitly to enable some of these features even in the presence of -ansi. By explicitly defining these in your code (say, in a configuration header), you effectively state to the human reading the source that you rely on non-ANSI APIs being exported in these otherwise standard headers.
The unfortunate mess that we've inherited has all of these non-standard APIs spewn across all of these standard headers. It's for that reason that tools like GNU autoconf exist. I'd rather these APIs all be confined to their own headers as you suggest. *sigh*
--Joe--
Program Intellivision!
So does Linux. Sometimes I wished Windows did.
At any rate, if you have your resource limits cranked up for some reason, or a privileged process develops a bug and goes ape-shit, well then... :-) As the poster a couple levels up said, the reason the one machine needed a reboot was because some in-house application did exactly that.
--Joe--
Program Intellivision!
Me, clueless about C? I think not. Email me sometime and we can compare notes. I could give a sh*t if this discussion were about Linux. The compiler's behavior was correct, and I'm sorry, but you were just simply wrong.
--Joe--
Program Intellivision!
Of course that works -- you have a prototype for flockOfMeese in scope. When you use the -ansi switch on GCC, the compiler defines the macro __STRICT_ANSI__, which causes the prototype for strdup to be excluded from string.h. This can be overridden by an application by explicitly enabling various non-ANSI featuresets by defining one of the following macros: __USE_SVID, __USE_BSD, __USE_XOPEN_EXTENDED. Each of these macros enables one of several non-ANSI API sets to be visible from the standard headers as a portability aid for other platforms which (unwisely) chose to export their APIs within the ANSI C headers. In an ideal world, these other interfaces would be exported in their own platform-specific headers.
Just because your example works under FreeBSD doesn't mean it's right. FreeBSD happens to allow some of the BSD-specific APIs to leak through the standard headers, even with -ansi on the compiler command line. Ideally, the ANSI-specified headers would only define the ANSI-specified APIs (particularly in the case of supplying -ansi -pedantic to the compiler).
And, BTW, this isn't just about Linux. I've run into the "strdup isn't part of ANSI C" problem on plenty of platforms, including Macintosh and on DSPs. In your example, the compiler was doing its job: It informed you that you were calling an API that was not defined in any of the headers you included, and since you were including only ANSI C compliant headers (made compliant by -ansi), you can then fix your program. Why else have compiler diagnostics? If anything, this says the FreeBSD headers are sloppy.
--Joe--
Program Intellivision!
No, Sony wouldn't allow adult content on Betamax, plain and simple. I'm sure had Sony not placed any such restrictions on Betamax, the format would've thrived for much, much longer.
--Joe--
Program Intellivision!
Uhm, two things of my own:
In short, it's your own damn fault for using -ansi while trying to use an API entry that's not part of ANSI C's standard library.
--Joe--
Program Intellivision!
I disagree. An application that starts thrashing the machine sometimes can only be brought under control via a reboot. Imagine if a privileged process starts the equivalent of
I don't care what OS you have, the easiest way to reign that one is is to reboot. Things get even worse if said task is allocating other resources along the way (such as file descriptors, network sockets, what-have-you).
--Joe--
Program Intellivision!
BTW, why do all of your periods come up as copyright symbols on my screen? Am I the only person who sees that?
--Joe--
Program Intellivision!
The bitrate is only 50% higher than a CD's bitrate (1.5Mbit/sec), so don't go creaming in your pants just yet.
The main difference the 1 bit/sample makes in this case is that your bandwidth theoretically stretches to a much higher (and quite ridiculous) 1.2MHz. Of course, the SNR is really, really low at 1.2MHz. For such a system, the effective dynamic range (and SNR) is inversely proportional to the frequency. You'll gain high-end range at the expense of high-end precision and range. Assuming they use something like sigma-delta demodulation to decode this into listenable audio, you also lose dynamic range over most of the listening band due to the concept of "slope overload".
(ObDisclaimer: That is, if I remember my signal processing courses from school correctly. I may program DSPs for a living, but that's because I'm a good coder, not because I was good with DSP theory. Most of what I do is other engineering, not actual signal processing.)
--Joe--
Program Intellivision!
Yup, which is why every few months I show up to work with signs plastered over the walls and on all of the entrances saying "Do not open attachments named whatever.exe". Currently we have signs saying "navidad.exe" that went up a couple days ago.
Also, depending on the nature of the virus, they will also disable the dial-in modem pools, turn all the file servers to read only, and damn near send everyone home for the day. Meanwhile, I'm sitting there, reading mail in mutt on my Solaris box wondering what all the commotion is about.
*sigh*--Joe
--
Program Intellivision!
I fail to see how this is a troll. I was being dead serious.
--Joe--
Program Intellivision!
It's sorta like a business-model patent. You could take the oldest profession, rephrase it in terms of a "method", and strap on "involving a computer" and/or "network", and voila! Get yourself a patent.
--Joe--
Program Intellivision!
Why don't you and the laser get a freakin' room?
--
Program Intellivision!
I don't see a noun form of affect in my Webster's. (Specifically, "Webster's II New Riverside Dictionary, Revised Edition.") Granted, it's not quite as comprehensive as, say, the Oxford English Dictionary, but it does do a pretty good job of covering the portion of the language people actually still use. ;-)
--Joe--
Program Intellivision!
ObGrammar: It might affect my office, and it may have an effect on my workplace, but I have no idea what an affect is or means.
--Joe (Feeling a little edgy today.)--
Program Intellivision!
You liked the flashbacks? I prefer flashbacks that actually flash back to scenes rather than introducing new material. Sorta like your English teacher tells you: Never introduce new information in a conclusion. These flashbacks tend to conclude various subplots, yet they introduce new information. Urgl!
--Joe--
Program Intellivision!
[OT: Hey great user #!!]
Basically, I enjoyed the movie as a "don't think to hard, sit back and enjoy the special FX" sort of movie, and that was about it. There was some bad science, the occasional correct science (such as the fire extinguisher in zero-G), and a fair amount of action. Not too bad.
But, it was definitely one of those movies that, as you get more distant from it, you realize how empty it was. Like a firework after it's been lit, the flash is gone, the wow is gone, and you're left with just so much hollow shell.
That said, the movie was worth it, but only because we got in with discount tickets so it was $3.00 a head instead of $7.00. W/out the discount tickets, I'd say wait for it to come out on VHS/DVD/Beta/Whatever and rent it from Ballbuster or something.
--Joe--
Program Intellivision!
I had a similar problem (root perms) when I installed one of the NS6 preview releases. It appears the installer honors your umask setting, and that ends up removing permission bits all throughout the install dirs. Not too bright, I guess.
The fix was to find and make all the files in the install dir globally readable, and files w/ the X bit executable. Something along the lines of:
find
Good luck.
--Joe--
Program Intellivision!
Depending on which version of Linux you're running, you could be running into threading bugs in Linux's libc. I found that upgrading my libc on my RH6.0 box to the same libc that's in RH6.2 made a bit of difference for Netscape (and Mozilla's) stability. It showed more for Mozilla.
--
Program Intellivision!
Is it showing 135MB for the RSS or the SIZE on xmms and kdeinit? If the RSS is that big, then top is confused. If the SIZE is that big, then perhaps one or both applications is (a) memory mapping some devices (sound card, perhaps) and that mapping is being counted towards the process, or (b) one or both is leaking / allocating large amounts of memory but never faulting it in.
Memory that's allocated but never faulted in won't show up in RAM or in swap.
--Joe--
Program Intellivision!