Oh, and queue the predictable (and incorrect) responses about how you can't "steal" digital images. To steal a photo or a picture, you would have to take a physical copy belonging to someone, and deprive someone else of that physical copy, without their permission according to SlashDot, but not the English dictionary.
Pet Peeve of mine: That's not the definition of "steal". It's only the SlashDot conventional wisdom. It's really not that hard to look up words on the internet. Here's a link to a dictionary.
Steal: 1 a: to take or appropriate without right or leave and with intent to keep or make use of wrongfully
Appropriate:
3 : to take or make use of without authority or right
As you've pointed out, stealing isn't always about physical posession, but copyright advocates (e.g, *IAA) frequently conflate this type of stealing with #3 (i.e., using without authority or right).
However, the top definition of steal is about physical posession and I think is obviously what most people mean by "steal" in most contexts. So although while using "steal" to refer to copyright infringement may be technically correct, it is misleading, at best.
If the only criterion is for it to be "the best", then, sure, it's totally underspecified and subjective.
But if you have specific goals, like "learnable by typical computer users" or "usable by accountants", then there are ways to measure them and improve them that aren't arbitrary.
One problem is that "usability" has many facets, and some of them are frequently in tension, such as "easy to learn" and "efficient for experts". (It's not that you *can't* have both, it's just harder.)
That really burns my biscuits! You mean Sega is going to force games containing content unsuitable for my impressionably proginy onto my Wii, strip the parental controls, and then force my kids to see them, with me in handcuffs so I can't properly supervise what they're doing?
What's that you say? I'd have to buy it? On purpose? And you're sure the disc won't jump out of its case and load itself up? And I won't be prevented from setting the parental controls in the wii, nor from monitoring my kids?
Completely agree. Spam was the bane of Usenet and the fundamental cause of its demise. I "was there" for the Green Card Lawyers spam (got the t-shirt, etc.), and in my mind that was the beginning of the end.
comp.sys.apple2 and rec.humor.funny, how I've missed you.
I guess this means soon I'll start getting a stream of Vista CDs in the mail and I can "upgrade" my coasters. Pretty handy in the hot & humid weather here, I'll tell you.
I used to have an impression of Pittsburgh that I think is shared by lots of Americans (and maybe more widely, for all I know): that it's a nasty, dirty old steel town.
But then I lived in Pittsburgh for a few years and really liked it. It's been cleaned up a lot and the rivers and hills make for some really pretty scenery. And the people are friendly, and it's an inexpensive place to live (esp. compared to the other two places I've spent substantial time: the Bay Area and the DC area). My wife and I think the city motto should be "Pittsburgh---cooler than you think!"
I agree with all your comments, *except* "e-mail only make[s] it worse". I think email can be the best communication medium by far for techies at work, because it's asychronous (and has nice properties of text, like being scannable, searchable, etc.).
My computer used to tell me whenever email arrived. But now it doesn't, and I love it that way. Now I can take full advantage of its asychronicity, and check it when I want to, so it doesn't interrupt me.
If one of my coworkers wants something from me *now*, they can IM, call, or drop by my office.
If you get notified every time email arrives, I strongly recommend you disable it.
(FYI, I am a software architect/designer/visionary/engineer/code monkey/pick-your-favorite-term.)
It's true that DARPA is part of the DoD, but the research it has sponsored in the past has given benefits far beyond the military. Examples of things it's sponsored include:
* Networking (the Internet)
* Graphics
* Timesharing systems
* VLSI
* RISC
* RAID
* Parallel and high-performance computing
As for not wanting to work there, it's like other comments have said: DARPA program managers don't *do* research, they manage people who do (and really it's more like: they manage people like professors and company project managers, and *those* people manage the students and scientists who actually *do* the research). People get PhDs for different reasons, of those who got one to do research, few of them want to be that far removed from actually doing it.
I agree that even (really) good programmers make mistakes when writing multi-threaded code. My point there was that if you're a lot better at something than most people, you may underestimate how hard it is and have unrealistic ideas about how well most people would do at it.
In the specific example of multithreading, I think a programmer of any skill will benefit from higher-level abstractions than pthreads. The point about skill level is that if the higher your skill level, the less it will probably hurt you (or at least the less you'll think it will) not to have the extra help from the language and/or libraries.
A lot of/. folks are extremely good programmers, and I think don't realize that what's easy for them is not easy for most people.
C and C++ are an easy languages to write buggy code in. People write working programs in them, and people also write buggy code in every language that anyone has written more than "Hello, world!" in. But this doesn't mean that all languages are equally easy to write bug-free code in. The flexibility and power C/C++ have (which is part of their appeal) also gives you a lot of rope to hang yourself with.
Similarly, lots of multi-threaded programs work, and lots of single-threaded programs are buggy. But multi-threaded programming is much, much harder than single-threaded. Also, the support provided by the language and libraries you use can make a *huge* difference. (The type of app, too, since some types are a lot easier to parallelize than others, but that's OT.)
I would especially like to object to anybody who says "Why are you whining about C/C++? They have pthreads, and that's enough." That's true in the same sense that in theory you could write any program in assembly or describe any computable algorithm in lambda calculus. Yes, you *can* write multi-threaded code in pthreads, but if that's all you have, it's pretty painful. What more could you want? For one thing, higher-level libraries like the Java Concurrency Libraries.
And it's not just a matter of having the "right" add-on concurrency/threading library. If you have a bunch of other libraries, like I/O, for example, that were designed with concurrency in mind, they might all, say, use SIGALARM for timeouts. If the app is single-threaded, no problem, but if not, you're in trouble. So really, you need a whole suite of libraries made to support concurrency.
A big problem with getting good examiners is compensation. I was not out to get the absolute highest paying job possible, but when I could get *twice* what the USPTO was offering working in industry, it was not a hard decision (esp. since the cost of living in the DC area is pretty darned high).
If they really want to improve patent quality, they should pay more, which would probably require either A) that the USPTO no longer have to pay for itself via fees or B) raise fees so high that almost no individual could get one.
It's GPLv3. I guess I should have been more specific about what I meant by "consistency". It's all legal (AFAIK, IANAL), I just meant that it's interesting to me that they talk about a "quid pro quo" on their licencing page as why they're dual-licencing and why the non-commercial license is GPL, but they selling software based on another company's OSS (GWT).
It's their software so they have every right to release it under whatever license they want (and I've never heard of it or them before, so it makes no difference to me), but I find it... interesting... that one of their products (Ext GWT) is based on a product that uses the Apache License (the Google Web Toolkit), while the Ext product uses GPL.
Re:Banks -- Not for everyone.
on
Matter
·
· Score: 1
Hear, hear. I completely agree that his books are not for all SF/fantasy fans. I don't know if they're representative of his work or not, but I was very unimpressed with the two I read: Use of Weapons and Feersum Endjinn. I think I just didn't get the former, since I kept wondering when it would get interesting and the end just left me saying "huh?" The latter was entertaining, but harder to understand than it needed to be, and far from the level of sophistication I would expect based on the review here and most of the comments.
Anyway, if you like Banks, cool. If you haven't read his stuff, I would recommend borrowing rather than buying your first one.
I agree: it's the docs. I am not a DBA, but I am a really experienced programmer (and multiple CS degrees, yadda yadda). I set up both PostgreSQL and MySQL a few years ago for really simple databases, and found that MySQL was a lot easier to get going. The Postgres docs seemed focused on being a reference, whereas I found much better tutorial-type information about MySQL.
Technically, I have thought for a long time that at least for big systems (and maybe even for not-so-big, I dunno), Postgres was definitely the better choice. But I think MySQL is above the bar for a huge fraction of database users out there, and even if it isn't, its ease of installation and configuration has made it and will keep making it the favorite.
It's true that dynamic displays are different from static ones. But there's another reason besides the staticness of paper that you might want to put a lot of data on the page/screen simultaneously: you might notice something interesting about the data if you can see more if it at the same time.
I used to be confused about why some modern art aficionados called some things "art" and others not. I now think the problem is that I always thought art was about the actual art--that is, the artifact the artist produces (painting, sculpture, etc.). But I think at least for modern art, it's all about the story around the artifact. By story I mean stuff like how the artifact fits in the artist's life, the process that was used to create it, what it says about Humanity's Struggle Against/For Whatever, etc. If there's a story about the artifact that's "suitable", then it's Art. Otherwise, not.
I'm not saying I think this is a good way to determine what to call "art" vs. what not to, but it seems like the operating principle for a lot of folks who talk about modern art.
Re:You will love Mr Rice's opinions on open source
on
Geekonomics
·
· Score: 1
Thanks a lot for the link to the author's reply on his blog. I now know I need not consider buying this book any longer.
His argument that the ability to continue to use (and improve and fix bugs in) a product someone else decided wasn't worth their while to contine working on is an economically bad thing is totally bizarre. I also think his terminology is unnecessarily biased. A developer choosing to work for company A instead of company B does not "rob" company B of their efforts.
I'd be kind of interested to know how large a "software product" has to be in his view before it requires regulation. Does 5 lines of JavaScript on my website qualify? What about a macro for OpenOffice, Word, Excel. etc.? Are the rules different if I sell them?
(Yes, I realize I could read the book to find out, but I'm not curious enough to give him my money, considering the strange arguments I've seen thus far.)
Thanks for the link to Linus's interpretation of GPL. I agree with him that copyright rights shouldn't depend on ln vs. mkisofs differences.
However, I'd appreciate it if someone could explain more about his argument that libc and libqt, for example, differ substantially in terms of derived works and GPL. In both cases, a program dynamically linked against one needs something that implements the same API in order to run. So if number of existing implementations is a problem, could I just write my own implementation of the API (one that maybe isn't as featureful), and then I'd be in the clear? (Granted, for libgt this would be a major undertaking, but for a smaller GPLed library it wouldn't be.) To me, this is a really weird argument.
A constant tension in "improving" the UI of an existing program is that the users say, "Make it better. But don't change anything."
This is sensible on their part, but makes life hard for UI designers. Up to a point, incremental improvements can do a lot for a lot of the UIs out there. (In fact, for most software out there, commercial and OSS, incremental work would go a *long* way toward improving usability.)
However, some improvements cannot be done incrementally. To pick an extreme example, textual, keyboard-based interfaces could never be incrementally improved to have a mouse-oriented UI.
I completely agree that there's value in having someone around who knows about what the software will actually be used for and isn't all about writing code just for its own sake. (That's fun, but not why businesses pay developers.) And some people with non-computer science backgrounds are awesome software developers.
However. I would definitely want at least a few people on my team with some training in CS, and some or most with training in software engineering. (This training could be from a degree program or not.) Why? CS because it's good to have someone around who knows some theory about stuff like algorithms, programming languages, etc. Software engineering because there's a *lot* more to writing software than just typing lines of code. There's requirements gathering, designing/architecting, testing, and build management, just to name a few activities.
I am mainly talking about building software by a team of programmers, for people who are not the team. In other circumstances, this may not apply (as much).
Based on my experience, I'd say that the reason so much software is so buggy is not that programmers are stupid, ignorant, uneducated, lazy, or whatever (although those may apply).
The main problem is that high-quality, robust software takes a lot longer to develop and/or is a lot more expensive. And it seems like people have decided that in many cases, they'd rather have the cheaper stuff.
I don't know if this is a rational decision or not, because it depends on how much extra cost lower-quality software incurs and how much more it would cost to make it better. But I think just saying "people are just stupid for not making it better" ignores the huge economic aspect.
Slashdot Mirror
Oh, and queue the predictable (and incorrect) responses about how you can't "steal" digital images. To steal a photo or a picture, you would have to take a physical copy belonging to someone, and deprive someone else of that physical copy, without their permission according to SlashDot, but not the English dictionary.
Pet Peeve of mine: That's not the definition of "steal". It's only the SlashDot conventional wisdom. It's really not that hard to look up words on the internet. Here's a link to a dictionary.
Steal:
1 a: to take or appropriate without right or leave and with intent to keep or make use of wrongfully
Appropriate:
3 : to take or make use of without authority or right
As you've pointed out, stealing isn't always about physical
posession, but copyright advocates (e.g, *IAA) frequently conflate
this type of stealing with #3 (i.e., using without authority or
right).
However, the top definition of steal is about physical
posession and I think is obviously what most people mean by "steal" in
most contexts. So although while using "steal" to refer to copyright
infringement may be technically correct, it is misleading, at best.
If the only criterion is for it to be "the best", then, sure, it's totally underspecified and subjective.
But if you have specific goals, like "learnable by typical computer users" or "usable by accountants", then there are ways to measure them and improve them that aren't arbitrary.
One problem is that "usability" has many facets, and some of them are frequently in tension, such as "easy to learn" and "efficient for experts". (It's not that you *can't* have both, it's just harder.)
That really burns my biscuits! You mean Sega is going to force games containing content unsuitable for my impressionably proginy onto my Wii, strip the parental controls, and then force my kids to see them, with me in handcuffs so I can't properly supervise what they're doing?
What's that you say? I'd have to buy it? On purpose? And you're sure the disc won't jump out of its case and load itself up? And I won't be prevented from setting the parental controls in the wii, nor from monitoring my kids?
Huh.
comp.sys.apple2 and rec.humor.funny, how I've missed you.
True, but don't forget Social Engineering. We need to switch from Free Market to Green and develop Cybernetic.
(Mmmm... thermal boreholes...)
I guess this means soon I'll start getting a stream of Vista CDs in the mail and I can "upgrade" my coasters. Pretty handy in the hot & humid weather here, I'll tell you.
I used to have an impression of Pittsburgh that I think is shared by lots of Americans (and maybe more widely, for all I know): that it's a nasty, dirty old steel town.
But then I lived in Pittsburgh for a few years and really liked it. It's been cleaned up a lot and the rivers and hills make for some really pretty scenery. And the people are friendly, and it's an inexpensive place to live (esp. compared to the other two places I've spent substantial time: the Bay Area and the DC area). My wife and I think the city motto should be "Pittsburgh---cooler than you think!"
I agree with all your comments, *except* "e-mail only make[s] it worse". I think email can be the best communication medium by far for techies at work, because it's asychronous (and has nice properties of text, like being scannable, searchable, etc.).
My computer used to tell me whenever email arrived. But now it doesn't, and I love it that way. Now I can take full advantage of its asychronicity, and check it when I want to, so it doesn't interrupt me.
If one of my coworkers wants something from me *now*, they can IM, call, or drop by my office.
If you get notified every time email arrives, I strongly recommend you disable it.
(FYI, I am a software architect/designer/visionary/engineer/code monkey/pick-your-favorite-term.)
It's true that DARPA is part of the DoD, but the research it has sponsored in the past has given benefits far beyond the military. Examples of things it's sponsored include:
* Networking (the Internet)
* Graphics
* Timesharing systems
* VLSI
* RISC
* RAID
* Parallel and high-performance computing
As for not wanting to work there, it's like other comments have said: DARPA program managers don't *do* research, they manage people who do (and really it's more like: they manage people like professors and company project managers, and *those* people manage the students and scientists who actually *do* the research). People get PhDs for different reasons, of those who got one to do research, few of them want to be that far removed from actually doing it.
Bzzzt. False dichotomy. Many Christians do not believe Christianity and evolution are incompatible.
Hmmm... Maybe I should put both on my car...
I agree that even (really) good programmers make mistakes when writing multi-threaded code. My point there was that if you're a lot better at something than most people, you may underestimate how hard it is and have unrealistic ideas about how well most people would do at it.
In the specific example of multithreading, I think a programmer of any skill will benefit from higher-level abstractions than pthreads. The point about skill level is that if the higher your skill level, the less it will probably hurt you (or at least the less you'll think it will) not to have the extra help from the language and/or libraries.
A lot of /. folks are extremely good programmers, and I think don't realize that what's easy for them is not easy for most people.
C and C++ are an easy languages to write buggy code in. People write working programs in them, and people also write buggy code in every language that anyone has written more than "Hello, world!" in. But this doesn't mean that all languages are equally easy to write bug-free code in. The flexibility and power C/C++ have (which is part of their appeal) also gives you a lot of rope to hang yourself with.
Similarly, lots of multi-threaded programs work, and lots of single-threaded programs are buggy. But multi-threaded programming is much, much harder than single-threaded. Also, the support provided by the language and libraries you use can make a *huge* difference. (The type of app, too, since some types are a lot easier to parallelize than others, but that's OT.)
I would especially like to object to anybody who says "Why are you whining about C/C++? They have pthreads, and that's enough." That's true in the same sense that in theory you could write any program in assembly or describe any computable algorithm in lambda calculus. Yes, you *can* write multi-threaded code in pthreads, but if that's all you have, it's pretty painful. What more could you want? For one thing, higher-level libraries like the Java Concurrency Libraries.
And it's not just a matter of having the "right" add-on concurrency/threading library. If you have a bunch of other libraries, like I/O, for example, that were designed with concurrency in mind, they might all, say, use SIGALARM for timeouts. If the app is single-threaded, no problem, but if not, you're in trouble. So really, you need a whole suite of libraries made to support concurrency.
A big problem with getting good examiners is compensation. I was not out to get the absolute highest paying job possible, but when I could get *twice* what the USPTO was offering working in industry, it was not a hard decision (esp. since the cost of living in the DC area is pretty darned high).
If they really want to improve patent quality, they should pay more, which would probably require either A) that the USPTO no longer have to pay for itself via fees or B) raise fees so high that almost no individual could get one.
It's GPLv3. I guess I should have been more specific about what I meant by "consistency". It's all legal (AFAIK, IANAL), I just meant that it's interesting to me that they talk about a "quid pro quo" on their licencing page as why they're dual-licencing and why the non-commercial license is GPL, but they selling software based on another company's OSS (GWT).
It's their software so they have every right to release it under whatever license they want (and I've never heard of it or them before, so it makes no difference to me), but I find it... interesting... that one of their products (Ext GWT) is based on a product that uses the Apache License (the Google Web Toolkit), while the Ext product uses GPL.
Anyway, if you like Banks, cool. If you haven't read his stuff, I would recommend borrowing rather than buying your first one.
I agree: it's the docs. I am not a DBA, but I am a really experienced programmer (and multiple CS degrees, yadda yadda). I set up both PostgreSQL and MySQL a few years ago for really simple databases, and found that MySQL was a lot easier to get going. The Postgres docs seemed focused on being a reference, whereas I found much better tutorial-type information about MySQL.
Technically, I have thought for a long time that at least for big systems (and maybe even for not-so-big, I dunno), Postgres was definitely the better choice. But I think MySQL is above the bar for a huge fraction of database users out there, and even if it isn't, its ease of installation and configuration has made it and will keep making it the favorite.
It's true that dynamic displays are different from static ones. But there's another reason besides the staticness of paper that you might want to put a lot of data on the page/screen simultaneously: you might notice something interesting about the data if you can see more if it at the same time.
I used to be confused about why some modern art aficionados called some things "art" and others not. I now think the problem is that I always thought art was about the actual art--that is, the artifact the artist produces (painting, sculpture, etc.). But I think at least for modern art, it's all about the story around the artifact. By story I mean stuff like how the artifact fits in the artist's life, the process that was used to create it, what it says about Humanity's Struggle Against/For Whatever, etc. If there's a story about the artifact that's "suitable", then it's Art. Otherwise, not.
I'm not saying I think this is a good way to determine what to call "art" vs. what not to, but it seems like the operating principle for a lot of folks who talk about modern art.
Thanks a lot for the link to the author's reply on his blog. I now know I need not consider buying this book any longer.
His argument that the ability to continue to use (and improve and fix bugs in) a product someone else decided wasn't worth their while to contine working on is an economically bad thing is totally bizarre. I also think his terminology is unnecessarily biased. A developer choosing to work for company A instead of company B does not "rob" company B of their efforts.
I'd be kind of interested to know how large a "software product" has to be in his view before it requires regulation. Does 5 lines of JavaScript on my website qualify? What about a macro for OpenOffice, Word, Excel. etc.? Are the rules different if I sell them?
(Yes, I realize I could read the book to find out, but I'm not curious enough to give him my money, considering the strange arguments I've seen thus far.)
Thanks for the link to Linus's interpretation of GPL. I agree with him that copyright rights shouldn't depend on ln vs. mkisofs differences.
However, I'd appreciate it if someone could explain more about his argument that libc and libqt, for example, differ substantially in terms of derived works and GPL. In both cases, a program dynamically linked against one needs something that implements the same API in order to run. So if number of existing implementations is a problem, could I just write my own implementation of the API (one that maybe isn't as featureful), and then I'd be in the clear? (Granted, for libgt this would be a major undertaking, but for a smaller GPLed library it wouldn't be.) To me, this is a really weird argument.
A constant tension in "improving" the UI of an existing program is that the users say, "Make it better. But don't change anything."
This is sensible on their part, but makes life hard for UI designers. Up to a point, incremental improvements can do a lot for a lot of the UIs out there. (In fact, for most software out there, commercial and OSS, incremental work would go a *long* way toward improving usability.)
However, some improvements cannot be done incrementally. To pick an extreme example, textual, keyboard-based interfaces could never be incrementally improved to have a mouse-oriented UI.
I completely agree that there's value in having someone around who knows about what the software will actually be used for and isn't all about writing code just for its own sake. (That's fun, but not why businesses pay developers.) And some people with non-computer science backgrounds are awesome software developers.
However. I would definitely want at least a few people on my team with some training in CS, and some or most with training in software engineering. (This training could be from a degree program or not.) Why? CS because it's good to have someone around who knows some theory about stuff like algorithms, programming languages, etc. Software engineering because there's a *lot* more to writing software than just typing lines of code. There's requirements gathering, designing/architecting, testing, and build management, just to name a few activities.
I am mainly talking about building software by a team of programmers, for people who are not the team. In other circumstances, this may not apply (as much).
Just wanted to chime in and say I can't remember the last time I saw a comment this good on /. Thanks!
Based on my experience, I'd say that the reason so much software is so buggy is not that programmers are stupid, ignorant, uneducated, lazy, or whatever (although those may apply).
The main problem is that high-quality, robust software takes a lot longer to develop and/or is a lot more expensive. And it seems like people have decided that in many cases, they'd rather have the cheaper stuff.
I don't know if this is a rational decision or not, because it depends on how much extra cost lower-quality software incurs and how much more it would cost to make it better. But I think just saying "people are just stupid for not making it better" ignores the huge economic aspect.