As far as practical applications go, I think that's the key phrase in your comment -- there are a lot of applications of CS; some of them don't require much math at all, some require just discrete math, some require discrete and continuous math, etc. To the extent that a CS degree is about practical applications, it generally covers enough ground to prepare you for as many possible situations as possible. So while you might not need to know about (eg) flow algorithms in your current job, you would have been able to deal with a job where they did come up.
That's aside from the benefits of theory for its own sake, which someone else already pointed out:)
LaTeX is great and all, but why would you need it on a live CD? (I also don't see the point of openoffice on a live CD, but I guess it's better than having idle space on the disk..)
There is discussion from time to time about optimizing for a more recent version of the x86 processors. So far no-one has presented convincing (ie, non-anecdotal; not subject to placebo effects) evidence that this actually makes things significantly faster for most packages. In addition, the more optimizations you do for one particular CPU variant, the more likelihood that you actually make things slower on others. For instance, targetting i586 is a terrible idea (according to common wisdom, anyway) because it actually decreases the performance of code on more recent x86 processors.
Some packages that do see significant benefit (for instance, OpenSSL, libc, the kernel) are already compiled for all x86 variants.
Valgrind is possibly the most useful debugging tool I've found lately. It's especially great for tracking down slippery memory bugs -- you know, the type that are virtually impossible to find using most debugging tools.
For people who haven't used it, what it basically does is recompile your program to target a simulated x86 CPU. It can detect branches that depend on uninitialized values, writes through a freed pointer, and a whole slew of other nasties that are difficult or impossible to detect with other tools.
A: "You look at me funny..." C: "I beat you senseless!"
A->C is not the same as ~C->~A.
A->C would be "If you look at me funny, I will beat you senseless!" taken as literal truth.
~C->~A would be "I will not beat you senseless if you do not look at me funny", and is not at all the same.
No, ~C->~A is "If I am not beating you senseless, you didn't look at me funny." Your statement above is ~A->~C, which, as you noted, is not logically equivalent to A->C.
If you are a member of Debian, as this comment seems to indicate, and you chose not to vote (or even to take five minutes to read the proposal)...I'm sorry, but you can't complain about the outcome. There's nothing stopping you from proposing a "put it back the way it was" GR on debian-vote, though, or even one that explicitly says "Debian is 100% Free Software, plus some non-free firmware and some GFDL-licensed stuff". (note, however, that it will need a 3:1 majority, and this proposal passed with over a 4:1 majority)
Here's some context for people who don't follow Debian matters habitually.
Debian has a document called the DFSG, or Debian Free Software Guidelines. These guidelines are used to determine whether software included in Debian is free: they require that the software be freely distributable, freely modifiable, etc. Stuff that doesn't meet these guidelines doesn't go on the CD images and is segregated into the "non-free" section of the archive; this policy is enshrined in Debian's Social Contract. More contextual information on the DFSG and its application is available here.
Now, historically, these guidelines have been applied to everything distributed by Debian. For instance, the Doom shareware.WAD went into non-free because its license forbade modification. However, some controversy has arisen in the last few years due to two developments: first, the FSF started using a new license (the "GNU Free Documentation License") for its documentation; more recently, there has been a trend for hardware manufacturers to require drivers to upload binary firmware code upon initialization.
Despite its name, the "GNU Free Documentation License" turned out not to meet the DFSG (you can read some unofficial explanations [URL redacted because I believe the author wishes to keep it private for the time being; I will post it later if he tells me it's ok; I'll badly summarize it by saying that Invariant Sections are the major issue but not the only problem]). Because this license was applied to documentation of large packages, such as libc and Emacs, because it claimed to be "Free", and because it was published by the FSF, some people felt that Debian should find a way to distribute software under this license in "main" even though it was clearly non-free according to the DFSG. The typical argument advanced to support this position was that "documentation is not software, so it doesn't need to meet the DFSG". This argument relied on an ambiguity in the meaning of the word "software": it can mean either "anything that's not hardware", or "sequences of instructions to be executed on the host microprocessor".
The firmware issue is somewhat different; there were some recent arguments on the debian-devel mailing list over whether binary firmware that is uploaded by an otherwise free driver should be moved to non-free. I haven't followed this as closely, and it only came up in the last month or two. (well, it has been discussed in the past, but the first serious discussion I'm aware of is in the last month or two)
The amendment that was recently passed changes the text of the Social Contract to make it clear that everything in the Debian archives (not just executable programs) should meet the DFSG. This was intended to settle the GFDL question once and for all.
The message referenced by this/. article is a post from the Release Manager indicating that he is changing his policy as a result of the GR. Until now, certain things that were unambiguously non-free, but where it was felt that the non-freeness was either not a regression (ie, they were non-free before and we didn't realize it and distributed them anyway), or where it would cause significant disruption to force the non-free item out of main (for instance, binary firmware), were being allowed to remain in Debian main until the release of sarge. Assuming that this message was sent in good faith, Anthony is indicating that he honestly believes that this was not previously a pragmatic exception to the Social Contract, and that no such pragmatic exception is possible now. Thus, he is now holding up the release until all this non-free stuff gets removed from main.
Discussion is ongoing on several Debian lists, and I don't think it's appropriate to make assumptions about the final outcome until things have settled down again.
I was looking recently at the Karma, Neuros and iRiver for something that I could use to record quality FM broadcasts from a local college station. Yes, I want multiple codecs, sync up to my collection via Ethernet, etc.
Note: some of these players have FM receivers but do not allow recording directly off FM.
I have a Neuros, and it does support recording directly from FM. (however, the reception is lousy enough that I haven't actually done this much -- easier to throw together a script to save their mp3 stream)
I do think, though, that whatever its problems, the early 2.6 series is in much better shape than the early 2.4 series was (remember that?). Of course, 2.6 has been nothing but stable for me, or I might think differently:).
If the info was outdated then it's doubtful you studied CS.
<pedant> This isn't entirely true -- in graduate courses that cover areas of current research, any textbooks that exist are, in fact, quite likely to be out of date. </pedant>
Think about it for a few minutes before modding me as a flame or troll. Mind you, it seems that/. has become more about moderation than discussion for many. Sad, really.
Personally, I think there should be a moderation score "+1, Misinformed". Combine it with "+1, Clueless" and "+1, Clueless and Proud of It", and you have an electronic recreation of the pillory!:-)
Short answer: the basic interface of the installer is the same (ie, text dialog screens), but a lot has changed under the hood (for instance, discover for hardware detection and parted to resize partitions -- not to mention that it should be a lot more maintainable) and the number of questions it asks has been substantially reduced.
Ok, you were thinking about apt-get. I think you missed my point: apt is a suite of tools and libraries, and apt-get is only one frontend. Talking about "apt" being hard to use simply doesn't make sense; it's like saying that "libc is hard to use", or "ext2 is hard to use".
Non-console frontends to apt exist; for instance, synaptic is said to be good by people who have used it (ie, not me:-) ).
link your app statically, or include all your depedancies in your package. that is the only solution to this problem.
Um, you realize that both of those options basically mean "send all your dependencies with the package"...which doesn't decrease the download time at all? Particularly if more than one program does it? (you can end up installing 50 copies of part of libXYZ.a instead of one shared copy)
What, you can't trigger spontaneous library calls by starting fixedly at your computer, then squinting really hard and grunting? I thought everyone could do that! Although I guess I wouldn't call it easy...
Or, um, did you have a specific apt interface you were thinking of?
Slashdot Mirror
depending on the programming you do
:)
As far as practical applications go, I think that's the key phrase in your comment -- there are a lot of applications of CS; some of them don't require much math at all, some require just discrete math, some require discrete and continuous math, etc. To the extent that a CS degree is about practical applications, it generally covers enough ground to prepare you for as many possible situations as possible. So while you might not need to know about (eg) flow algorithms in your current job, you would have been able to deal with a job where they did come up.
That's aside from the benefits of theory for its own sake, which someone else already pointed out
Daniel
I have to agree: bittorrent's speed is beyond belief.
Daniel
PS: yes, I read the FAQ and poked appropriate holes in my NAT.
LaTeX is great and all, but why would you need it on a live CD? (I also don't see the point of openoffice on a live CD, but I guess it's better than having idle space on the disk..)
Daniel
There is discussion from time to time about optimizing for a more recent version of the x86 processors. So far no-one has presented convincing (ie, non-anecdotal; not subject to placebo effects) evidence that this actually makes things significantly faster for most packages. In addition, the more optimizations you do for one particular CPU variant, the more likelihood that you actually make things slower on others. For instance, targetting i586 is a terrible idea (according to common wisdom, anyway) because it actually decreases the performance of code on more recent x86 processors.
Some packages that do see significant benefit (for instance, OpenSSL, libc, the kernel) are already compiled for all x86 variants.
Daniel
AOL.
Valgrind is possibly the most useful debugging tool I've found lately. It's especially great for tracking down slippery memory bugs -- you know, the type that are virtually impossible to find using most debugging tools.
For people who haven't used it, what it basically does is recompile your program to target a simulated x86 CPU. It can detect branches that depend on uninitialized values, writes through a freed pointer, and a whole slew of other nasties that are difficult or impossible to detect with other tools.
Daniel
A: "You look at me funny..."
C: "I beat you senseless!"
A->C is not the same as ~C->~A.
A->C would be "If you look at me funny, I will beat you senseless!" taken as literal truth.
~C->~A would be "I will not beat you senseless if you do not look at me funny", and is not at all the same.
No, ~C->~A is "If I am not beating you senseless, you didn't look at me funny." Your statement above is ~A->~C, which, as you noted, is not logically equivalent to A->C.
Daniel
I wish I had known to go vote on that one.
If you are a member of Debian, as this comment seems to indicate, and you chose not to vote (or even to take five minutes to read the proposal)...I'm sorry, but you can't complain about the outcome. There's nothing stopping you from proposing a "put it back the way it was" GR on debian-vote, though, or even one that explicitly says "Debian is 100% Free Software, plus some non-free firmware and some GFDL-licensed stuff". (note, however, that it will need a 3:1 majority, and this proposal passed with over a 4:1 majority)
Daniel
Just a note: a reference on the GFDL that has been publically posted is available here.
Daniel
Here's some context for people who don't follow Debian matters habitually.
.WAD went into non-free because its license forbade modification. However, some controversy has arisen in the last few years due to two developments: first, the FSF started using a new license (the "GNU Free Documentation License") for its documentation; more recently, there has been a trend for hardware manufacturers to require drivers to upload binary firmware code upon initialization.
/. article is a post from the Release Manager indicating that he is changing his policy as a result of the GR. Until now, certain things that were unambiguously non-free, but where it was felt that the non-freeness was either not a regression (ie, they were non-free before and we didn't realize it and distributed them anyway), or where it would cause significant disruption to force the non-free item out of main (for instance, binary firmware), were being allowed to remain in Debian main until the release of sarge. Assuming that this message was sent in good faith, Anthony is indicating that he honestly believes that this was not previously a pragmatic exception to the Social Contract, and that no such pragmatic exception is possible now. Thus, he is now holding up the release until all this non-free stuff gets removed from main.
Debian has a document called the DFSG, or Debian Free Software Guidelines. These guidelines are used to determine whether software included in Debian is free: they require that the software be freely distributable, freely modifiable, etc. Stuff that doesn't meet these guidelines doesn't go on the CD images and is segregated into the "non-free" section of the archive; this policy is enshrined in Debian's Social Contract. More contextual information on the DFSG and its application is available here.
Now, historically, these guidelines have been applied to everything distributed by Debian. For instance, the Doom shareware
Despite its name, the "GNU Free Documentation License" turned out not to meet the DFSG (you can read some unofficial explanations [URL redacted because I believe the author wishes to keep it private for the time being; I will post it later if he tells me it's ok; I'll badly summarize it by saying that Invariant Sections are the major issue but not the only problem]). Because this license was applied to documentation of large packages, such as libc and Emacs, because it claimed to be "Free", and because it was published by the FSF, some people felt that Debian should find a way to distribute software under this license in "main" even though it was clearly non-free according to the DFSG. The typical argument advanced to support this position was that "documentation is not software, so it doesn't need to meet the DFSG". This argument relied on an ambiguity in the meaning of the word "software": it can mean either "anything that's not hardware", or "sequences of instructions to be executed on the host microprocessor".
The firmware issue is somewhat different; there were some recent arguments on the debian-devel mailing list over whether binary firmware that is uploaded by an otherwise free driver should be moved to non-free. I haven't followed this as closely, and it only came up in the last month or two. (well, it has been discussed in the past, but the first serious discussion I'm aware of is in the last month or two)
The amendment that was recently passed changes the text of the Social Contract to make it clear that everything in the Debian archives (not just executable programs) should meet the DFSG. This was intended to settle the GFDL question once and for all.
The message referenced by this
Discussion is ongoing on several Debian lists, and I don't think it's appropriate to make assumptions about the final outcome until things have settled down again.
Daniel
Would you feel comfortable recommending Neuros to a non-geek who is keen to learn to use a new player
My younger brother is planning to major in English, and I practically had to physically pry my Neuros away from him once he got a look at it.
Daniel
I was looking recently at the Karma, Neuros and iRiver for something that I could use to record quality FM broadcasts from a local college station. Yes, I want multiple codecs, sync up to my collection via Ethernet, etc.
Note: some of these players have FM receivers but do not allow recording directly off FM.
I have a Neuros, and it does support recording directly from FM. (however, the reception is lousy enough that I haven't actually done this much -- easier to throw together a script to save their mp3 stream)
Daniel
Forget aliens, God, whatever. These spontaneous combustions are caused by the Wee Wigglums!
Daniel
I do think, though, that whatever its problems, the early 2.6 series is in much better shape than the early 2.4 series was (remember that?). Of course, 2.6 has been nothing but stable for me, or I might think differently :).
Daniel
If the info was outdated then it's doubtful you studied CS.
<pedant>
This isn't entirely true -- in graduate courses that cover areas of current research, any textbooks that exist are, in fact, quite likely to be out of date.
</pedant>
Daniel
Daniel
You probably didn't find a third-party program because OGG *comes* with a decoder that can do this, called ogg123.
Daniel
Think about it for a few minutes before modding me as a flame or troll. Mind you, it seems that /. has become more about moderation than discussion for many. Sad, really.
:-)
Personally, I think there should be a moderation score "+1, Misinformed". Combine it with "+1, Clueless" and "+1, Clueless and Proud of It", and you have an electronic recreation of the pillory!
Daniel
Short answer: the basic interface of the installer is the same (ie, text dialog screens), but a lot has changed under the hood (for instance, discover for hardware detection and parted to resize partitions -- not to mention that it should be a lot more maintainable) and the number of questions it asks has been substantially reduced.
Daniel
pork isn't in stable, but ntaim is.
Daniel
Yes, but the contrapositive of a statement is a trivial corollary of that statement :)
Daniel
Ok, you were thinking about apt-get. I think you missed my point: apt is a suite of tools and libraries, and apt-get is only one frontend. Talking about "apt" being hard to use simply doesn't make sense; it's like saying that "libc is hard to use", or "ext2 is hard to use".
:-) ).
Non-console frontends to apt exist; for instance, synaptic is said to be good by people who have used it (ie, not me
Daniel
it's very clear that *ideas* are not copyrightable
Tell that to the FreeCraft folks.
Daniel
over 70% of the planet does not have boradband
[snip]
link your app statically, or include all your depedancies in your package. that is the only solution to this problem.
Um, you realize that both of those options basically mean "send all your dependencies with the package"...which doesn't decrease the download time at all? Particularly if more than one program does it? (you can end up installing 50 copies of part of libXYZ.a instead of one shared copy)
Daniel
Hm, so you're saying I can, eg, install FreeBSD packages on NetBSD?
Daniel
apt isn't easy to use
What, you can't trigger spontaneous library calls by starting fixedly at your computer, then squinting really hard and grunting? I thought everyone could do that! Although I guess I wouldn't call it easy...
Or, um, did you have a specific apt interface you were thinking of?
Daniel