The day when I can stick an expansion card into a Linux system and have it simply work is the day I consider using it, not before.
That day would be today. Or quite a while ago, even... at least if the hardware in question is something like a sound card or video card or such. I'm not sure 'bout autoconfiguration on video capture cards -- haven't tried that lately -- but generally speaking, modern distributions' hardware detection is quite good. (By "modern distributions" I'm mostly referring to Red Hat 9 and KNOPPIX).
That said... I haven't tried Kylix, but it's not really the kind of thing that floats my boat anyhow. I do Java, C and Python development; wrt Java, Eclipse is considered by many to be among the better IDEs on any environment -- and works on Linux as well as Windows, though a bit slower on midrange hardware. As for C... well, call me old-fashoned, but when writing C I'm just as happy without one of those new-fangled IDE things anyhow. (Last time I tried using Visual Studio I was too busy being annoyed at the silly MS compiler being unable to handle syntax like "(a ? b : c) = d" to notice any nifty features the IDE might have had)... and writing Python, hell, *nix is where the development tools are native to anyhow (and stuff like the python bindings to libglade make throwing together quick GUI prototypes / one-offs / whatever a snap).
All in all, I consider Linux a *far* friendlier development environment. Hell, if some library isn't doing what I expect it to, I can trace down into its code... if I'm writing a driver I can run it inside a user-mode port of the OS and attach my regular source-level debugger to it and trace around inside the OS... try doing *that* in Windows!
Not having tools like strace and ltrace when I'm on Windows is another one of those things that makes my life a pain there... from where I stand (especially when doing integration work) those tools -- simple as they may be -- are worth more than whatever eye candy some fancy IDE might provide any day.
WRT Photoshop, it runs on Linux now -- as long as you own a copy of Crossover Office, which is cheap. Can't comment on DTP, as it's not something I do -- frankly, btw, I'm suprised that Adobe didn't follow up their FrameMaker Linux beta with a commercially supported port yet.
The concern is that there will be some attempted changes to what is considered "linking" (with regard to creation of derivative works) to increase the viral nature of the GPL in cases where no actual inclusion of the GPL-covered code into the would-be derivative work is done (as where a free ASP-type interface is used by a non-free client). There is of course a legal limit with regard to what can be considered a derivative work, but RMS (or was it Bruce Perens? Not sure which) has mentioned something regarding a potential workaround for that. (Sorry, can't re-find my reference wrt that).
Any change potentially increasing (or otherwise modifying) the viral nature of the GPL is something I'll want to review before making my software subject to it.
However, most GPL'ed software says that the license is something along the lines of "version 2 or whatever is the latest version". If "version 2" of the GPL is invalidated, there would soon be a "version 3" that solved whatever grounds "version 2" was invalidated on that would be applied to GPL'ed software.
Actually, there's an increasing number of Free Software developers (myself among them) who are explicitly unwilling to license our software under Version 3 of the GPL. Go read what RMS has planned for it -- basically it's intended to become much, much more incompatible with non-GPL software licenses.
Beg to differ. Almost all motherboard-integrated audio has a s/n ratio somewhere between "bad" and "horrid", and at least half of them either depend on software MIDI synthesis or include hardware synth so bad that most people today think MIDI sucks. (I happen to have a Roland RS-9 hooked up to my system I use for MIDI synth -- it's also a damn fine keyboard for the price).
Yes, if you're using the speakers that came with your computer and not going anywhere near MIDI synthesis, the onboard audio probably is fine for you. That's not to say it's fine for everyone.
IBM has a major presence in Austin -- and one of the things they've been able to use as a (quite lucerative) bargaining chip with potential customers is use of their local labs to port our software (which already runs on Linux) to their big-iron hardware (or to AIX).
I'm curious whether their Russian "Linux Competency Center" will also have an AIX box or two available -- basically, I'd be unsuprised if this is something completely new for them as opposed to having similar facilities elsewhere.
Huh? I don't at all see where you're going with that, but it sounds like you're implying that those who believe this student's actions should be legal are arguing that "stealing unlocked cards" shouldn't be a crime.
This is rediculous, though -- he's not stealing anything. We have no reason to believe that this student is distributing illegal copies or using the techniques he's learned to create copies for anything other than legitimate personal use (space-shifting, backup, etc).
And I suggest you look up "metaphor" in a dictionary, because the comparison you provided isn't worded as one.
Bad example. If water is flowing all over the floor, it's obvious where the problem is.
If you're only getting a trickle of water, though, and you don't have the skills to determine whether it's your internal plumbing or not -- calling the water department is reasonable.
Well, for one thing, you need to have a real dispute to go to court. Pretending to take a position you don't just for the sake of setting precedent is illegal (and, IMNSHO, well should it be).
Actually, that's not true. The RIAA has not won a single lawsuit against a P2P company since Napster.
Oh, I'm sorry -- is Napster not a P2P company? Because if they were, then my statement (that at least one P2P company and at least one P2P user have been succesfully sued) would in fact be true.
oh, I meant the price of P2P software will increase
Huh? The price that's paid to the remaining producers of download-facilitation software will increase if the set of suppliers is reduced. That's what I was saying at the beginning, and it's what I'm saying now.
Granted, I intentionally used some wording that made fun of the whole economics thing, and you then used that in your jest -- but the difference that my jest was meant to be a bit of a laugh while supporting the idea that attacking the supply of downloading software (rather than the demand) is inherently futile, while your response struck me as being in favor of an opposing position.
The P2P companies aren't sharing materials; the users of their software are.
What's your point? The users are (largely) guilty of copyright violation; the companies are (largely) guilty of knowingly facilitating them in this. Either is a fine target, and both have been succesfully sued.
The RIAA shutting down the "sharers" has no (direct) effect on the P2P companies.
Whatever your motivation, be it ego or advertising dollars -- take away your user base, and you no longer get any.
So the price isn't mandatory cost of the software -- but folks who build P2P systems still have *some* kind of motivation, right?
Maybe it's ego -- doing something daring, dangerous and flashy. If there's plenty of supply of P2P software, folks running Yet Another P2P Network don't get nearly the ego boost as they would if they were one of a few and there were a huge crowd interested.
Maybe it's banner advertising money. If there are fewer P2P programs out there to buy banner ad space on, then that's all the more views (and thus income) for those that still exist.
Maybe it's monetary donations from users (either in response for a fancied-up version of the software or otherwise). Less competition -> more donations.
Then it's a BSD license -- not "public domain" as has been so frequently stated 'round here.
That said, it'll be hard to show that one was damaged by 200 lines of publicly available code being used unattributed. It'll also be interesting to see if an alternate, truly public domain source is available for that code.
Except that stemming the supply without decreasing demand means an increase in price, and thus incentive for those suppliers who are left to increase their operations, and for new suppliers to enter the market.
Trying to kill a thing by cutting off the supply is a Really Bad Idea.
Perhaps you haven't heard of this thing called "public domain". See, when something is in public domain, copyright can't be enforced with regard to it. Sooo, even if the code in question *was* originally written as part of SysV, if it's in the public domain, no harm, no foul. (And anyhow, damages for 200 lines of code implementing a very well-known algorithm can't be very high).
Well, first they aren't claiming 3B in lost sales. They are claiming 1B in damages, which in federal court automaticaly gets trippled to 3B.
Not quite "automatically" -- it's tripled if the infringement can be shown to be willfull. (That's not a full explanation of when treble damages apply -- it's been to long since I studied business law -- but IIRC it's the relevant factor here).
Presuming that one already knows the poem, I think the grandparent post is kind of funny -- it's at least interesting to see a different spin.
(Yes, it [the post] makes light of a gravely important concept... but what good's humor if it can only make light of things that aren't all that heavy to begin with?)
Agreed. Perhaps an os.path.realpath() call combined with a strncmp?
(Yes, I know the C standard library doesn't have realpath; it's from Python, but the base implementation is C. Apache, IIRC, also has similar code. The advantage of this over simply outlawing "." or ".." altogether is that it also prevents escape from the shared tree via symlinks).
Typical procedure in a case like this is to disassemble the program you're analyzing (and so get assembly code source) and then to write an exploit in whatever language you're comfortable in (in this case C++, bah).
So... the source here was written by the guy who found the exploit, presumably based on a disassembled copy of the program. Does that explain things adequately?
A buffer overflow involves, guess it, overflowing a buffer. Putting a different byte in the command field of a packet -- without any changes in length -- is absolutely not a buffer overflow.
Jumping to a delete routine based on what's in that byte is not a "deliberate mistake".
As nice as it would be to do a bit of wishful thinking -- as a professional coder, I can state this behaviour was clearly intentionally added.
To an embedded systems company, the desktop is not only minor but irrelevant. Folks in embedded space care about how small and stable the core system is; few embedded applications have any graphical involvement at all.
Almost all the cases I know of where folks have decided against Linux in embedded space have been not because it's immature or insufficiently functional, but because it's too damn big.
(One of the up-and-coming OSes I think has a very strong chance of becoming a strong competitor in embedded space has a kernel of about 38 kilobites. Contrast that to Linux, which can't be pruned far below half a mb and is becoming more and more unsuitable for tiny systems as time goes on... see the problem?)
Anyhow, the desktop is about as far from embedded folks' minds as anything.
Slashdot Mirror
The day when I can stick an expansion card into a Linux system and have it simply work is the day I consider using it, not before.
That day would be today. Or quite a while ago, even... at least if the hardware in question is something like a sound card or video card or such. I'm not sure 'bout autoconfiguration on video capture cards -- haven't tried that lately -- but generally speaking, modern distributions' hardware detection is quite good. (By "modern distributions" I'm mostly referring to Red Hat 9 and KNOPPIX).
That said... I haven't tried Kylix, but it's not really the kind of thing that floats my boat anyhow. I do Java, C and Python development; wrt Java, Eclipse is considered by many to be among the better IDEs on any environment -- and works on Linux as well as Windows, though a bit slower on midrange hardware. As for C... well, call me old-fashoned, but when writing C I'm just as happy without one of those new-fangled IDE things anyhow. (Last time I tried using Visual Studio I was too busy being annoyed at the silly MS compiler being unable to handle syntax like "(a ? b : c) = d" to notice any nifty features the IDE might have had)... and writing Python, hell, *nix is where the development tools are native to anyhow (and stuff like the python bindings to libglade make throwing together quick GUI prototypes / one-offs / whatever a snap).
All in all, I consider Linux a *far* friendlier development environment. Hell, if some library isn't doing what I expect it to, I can trace down into its code... if I'm writing a driver I can run it inside a user-mode port of the OS and attach my regular source-level debugger to it and trace around inside the OS... try doing *that* in Windows!
Not having tools like strace and ltrace when I'm on Windows is another one of those things that makes my life a pain there... from where I stand (especially when doing integration work) those tools -- simple as they may be -- are worth more than whatever eye candy some fancy IDE might provide any day.
WRT Photoshop, it runs on Linux now -- as long as you own a copy of Crossover Office, which is cheap. Can't comment on DTP, as it's not something I do -- frankly, btw, I'm suprised that Adobe didn't follow up their FrameMaker Linux beta with a commercially supported port yet.
I'm just curious: What kind of work do you do such that good tools aren't available for Linux?
See the bits about "closing the ASP loophole":
3 62 02
http://newsforge.com/article.pl?sid=00/11/01/16
The concern is that there will be some attempted changes to what is considered "linking" (with regard to creation of derivative works) to increase the viral nature of the GPL in cases where no actual inclusion of the GPL-covered code into the would-be derivative work is done (as where a free ASP-type interface is used by a non-free client). There is of course a legal limit with regard to what can be considered a derivative work, but RMS (or was it Bruce Perens? Not sure which) has mentioned something regarding a potential workaround for that. (Sorry, can't re-find my reference wrt that).
Any change potentially increasing (or otherwise modifying) the viral nature of the GPL is something I'll want to review before making my software subject to it.
However, most GPL'ed software says that the license is something along the lines of "version 2 or whatever is the latest version". If "version 2" of the GPL is invalidated, there would soon be a "version 3" that solved whatever grounds "version 2" was invalidated on that would be applied to GPL'ed software.
Actually, there's an increasing number of Free Software developers (myself among them) who are explicitly unwilling to license our software under Version 3 of the GPL. Go read what RMS has planned for it -- basically it's intended to become much, much more incompatible with non-GPL software licenses.
Beg to differ. Almost all motherboard-integrated audio has a s/n ratio somewhere between "bad" and "horrid", and at least half of them either depend on software MIDI synthesis or include hardware synth so bad that most people today think MIDI sucks. (I happen to have a Roland RS-9 hooked up to my system I use for MIDI synth -- it's also a damn fine keyboard for the price).
Yes, if you're using the speakers that came with your computer and not going anywhere near MIDI synthesis, the onboard audio probably is fine for you. That's not to say it's fine for everyone.
IBM has a major presence in Austin -- and one of the things they've been able to use as a (quite lucerative) bargaining chip with potential customers is use of their local labs to port our software (which already runs on Linux) to their big-iron hardware (or to AIX).
I'm curious whether their Russian "Linux Competency Center" will also have an AIX box or two available -- basically, I'd be unsuprised if this is something completely new for them as opposed to having similar facilities elsewhere.
Huh? I don't at all see where you're going with that, but it sounds like you're implying that those who believe this student's actions should be legal are arguing that "stealing unlocked cards" shouldn't be a crime.
This is rediculous, though -- he's not stealing anything. We have no reason to believe that this student is distributing illegal copies or using the techniques he's learned to create copies for anything other than legitimate personal use (space-shifting, backup, etc).
And I suggest you look up "metaphor" in a dictionary, because the comparison you provided isn't worded as one.
Bad example. If water is flowing all over the floor, it's obvious where the problem is.
If you're only getting a trickle of water, though, and you don't have the skills to determine whether it's your internal plumbing or not -- calling the water department is reasonable.
Well, for one thing, you need to have a real dispute to go to court. Pretending to take a position you don't just for the sake of setting precedent is illegal (and, IMNSHO, well should it be).
Actually, that's not true. The RIAA has not won a single lawsuit against a P2P company since Napster.
Oh, I'm sorry -- is Napster not a P2P company? Because if they were, then my statement (that at least one P2P company and at least one P2P user have been succesfully sued) would in fact be true.
oh, I meant the price of P2P software will increase
Huh? The price that's paid to the remaining producers of download-facilitation software will increase if the set of suppliers is reduced. That's what I was saying at the beginning, and it's what I'm saying now.
Granted, I intentionally used some wording that made fun of the whole economics thing, and you then used that in your jest -- but the difference that my jest was meant to be a bit of a laugh while supporting the idea that attacking the supply of downloading software (rather than the demand) is inherently futile, while your response struck me as being in favor of an opposing position.
The P2P companies aren't sharing materials; the users of their software are.
What's your point? The users are (largely) guilty of copyright violation; the companies are (largely) guilty of knowingly facilitating them in this. Either is a fine target, and both have been succesfully sued.
The RIAA shutting down the "sharers" has no (direct) effect on the P2P companies.
Whatever your motivation, be it ego or advertising dollars -- take away your user base, and you no longer get any.
*heh*. I knew that was coming.
So the price isn't mandatory cost of the software -- but folks who build P2P systems still have *some* kind of motivation, right?
Maybe it's ego -- doing something daring, dangerous and flashy. If there's plenty of supply of P2P software, folks running Yet Another P2P Network don't get nearly the ego boost as they would if they were one of a few and there were a huge crowd interested.
Maybe it's banner advertising money. If there are fewer P2P programs out there to buy banner ad space on, then that's all the more views (and thus income) for those that still exist.
Maybe it's monetary donations from users (either in response for a fancied-up version of the software or otherwise). Less competition -> more donations.
And so forth.
Then it's a BSD license -- not "public domain" as has been so frequently stated 'round here.
That said, it'll be hard to show that one was damaged by 200 lines of publicly available code being used unattributed. It'll also be interesting to see if an alternate, truly public domain source is available for that code.
Except that stemming the supply without decreasing demand means an increase in price, and thus incentive for those suppliers who are left to increase their operations, and for new suppliers to enter the market.
Trying to kill a thing by cutting off the supply is a Really Bad Idea.
On the bright side, at least he was familiar with the poem. Most people probably won't get the reference.
I think it's better known than you think. I've run into in multiple times, the first of them (if my memory serves) in a US public school.
Perhaps you haven't heard of this thing called "public domain". See, when something is in public domain, copyright can't be enforced with regard to it. Sooo, even if the code in question *was* originally written as part of SysV, if it's in the public domain, no harm, no foul. (And anyhow, damages for 200 lines of code implementing a very well-known algorithm can't be very high).
It was System V code that SGI did indeed add to Linux -- but it was in the public domain already, anyhow, so no harm no foul. Unless you're SCO.
I believe the SGI letter details this, though I'd heard it independantly earier.
Well, first they aren't claiming 3B in lost sales. They are claiming 1B in damages, which in federal court automaticaly gets trippled to 3B.
Not quite "automatically" -- it's tripled if the infringement can be shown to be willfull. (That's not a full explanation of when treble damages apply -- it's been to long since I studied business law -- but IIRC it's the relevant factor here).
Eh?
Presuming that one already knows the poem, I think the grandparent post is kind of funny -- it's at least interesting to see a different spin.
(Yes, it [the post] makes light of a gravely important concept... but what good's humor if it can only make light of things that aren't all that heavy to begin with?)
Agreed. Perhaps an os.path.realpath() call combined with a strncmp?
(Yes, I know the C standard library doesn't have realpath; it's from Python, but the base implementation is C. Apache, IIRC, also has similar code. The advantage of this over simply outlawing "." or ".." altogether is that it also prevents escape from the shared tree via symlinks).
Yes, I'll agree that that part is almost certainly a bug.
Huh?
Typical procedure in a case like this is to disassemble the program you're analyzing (and so get assembly code source) and then to write an exploit in whatever language you're comfortable in (in this case C++, bah).
So... the source here was written by the guy who found the exploit, presumably based on a disassembled copy of the program. Does that explain things adequately?
You're obviously not a coder.
A buffer overflow involves, guess it, overflowing a buffer. Putting a different byte in the command field of a packet -- without any changes in length -- is absolutely not a buffer overflow.
Jumping to a delete routine based on what's in that byte is not a "deliberate mistake".
As nice as it would be to do a bit of wishful thinking -- as a professional coder, I can state this behaviour was clearly intentionally added.
Um, so users can delete a file from inside the P2P program?
If you're writing a routine to let the user delete files, you don't hook it up to the network command-parsing routines.
Duh.
To an embedded systems company, the desktop is not only minor but irrelevant. Folks in embedded space care about how small and stable the core system is; few embedded applications have any graphical involvement at all.
Almost all the cases I know of where folks have decided against Linux in embedded space have been not because it's immature or insufficiently functional, but because it's too damn big.
(One of the up-and-coming OSes I think has a very strong chance of becoming a strong competitor in embedded space has a kernel of about 38 kilobites. Contrast that to Linux, which can't be pruned far below half a mb and is becoming more and more unsuitable for tiny systems as time goes on... see the problem?)
Anyhow, the desktop is about as far from embedded folks' minds as anything.