"I've asked this every time this topic comes up. Can anyone name a SINGLE piece of open source software that does anything better than it's closest closed source (or otherwise "proprietary" via patents or whatever) counterpart?"
Who are you quoting?
I can simply point to my dpkg -l listing, from
at to zsh (alsa sucks and the others before at are kind of support packages).
Free software which uses the traditional Unix user interfaces
is usually superior to anything proprietary, if it even exists.
Old Velvia was 50ASA which was insanely slow, and hard to shoot with. Wonderful with tripod but handheld was hard. I actually found it a bit over saturated, though that's a matter of opinion.
ISO 50 isn't so slow.Once upon a time that would have been considered medium speed. Kodachrome was once offered at ISO 25, and I've heard of some older films going down to ISO 8. Now THAT's slow!
And the best known Kodachrome is Kodachrome 64 at "just" ISO 64, isn't it?
Back in the late 1980s when I shot slides a lot, I tended to use ISO 200 film -- but I was
painfully aware that Kodachrome 64 would have produced better colors and sharpness.
I traded quality for convenience.
You mean other than the fact that the statement is bullshit? I have a compiled version of Tomboy and it only comes out to around 5-6 megs.
You're probably right, but 5--6 megs is a lot, too.
On my system, the only binary larger than that is emacs (at 6.7 megs).
(Oh, I know there are lots of other things which need disk space, but I can't be bothered to find
out how to sort my dpkgs by install size.)
Not that any of this really concerns me. I don't let Gnome come anywhere near my
three or four Debian systems. Nor KDE for that matter.
Basically we had what is sometimes called "weak code ownership" where it was clear that each module was "owned" by one or two people, but anyone was free to examine the code, or even modify the code if they discussed the changes with the owner. It's a really pleasant and productive way to work, and I highly recommend it, if you can find the right company.
That paragraph scares me, because you suggest that there are workplaces where you're
*not* supposed to look at anyone else's code. That would be a really stupid system.
In my experience, it's usually the "guest" (myself included) who is too reluctant to read it.
In addition to that, you might want to consider better tooling. If you're doing reviews by sending.diff files over email, you're doing it wrong - there are many specialized tools out there that will do automatic and smart diffing (including between rounds in a multi-round CR), notify people responsible for affected files, allow to set up the workflow according to your needs, enable attaching review comments and conversations to particular files and lines of code, and so on.
Do people really send patches around for review?
I distrust fancy collaboration tools.
All you need is the label/tag in the version control system and everything is
there: the actual code and other files (e.g. user documentation) to review, and the
checkin comments leading up to it.
Maybe the review comments should also go into version control, so what you eventually
merge is (a) the code under review +
(b) review comments pointing out what sucks +
(c) the changes which eliminate the review comments and the
(if the comments where valid) things they complained about.
Unless there's a bug in the system. In which case, your phone stops working when you need it the most. I can't help thinking that better power saving in normal operation might be a better solution. Easier to find bugs in normal operation too.
Exactly. 911 calls would now be executed in a brand environment which most phones never
enter. If you're lucky, the phone vendor has tested 911 calls, but it hasn't
seen much real field testing. And dead people don't file bug reports...
Except that the old saying was originally to do with physical possibilities and team effort. If a special forces member loses an arm, he is no good in the field, but very useful at boot camp.
That sounds right, in a Michael-Ironside-in-Starship-Troopers kind of way.
"If you can no longer do Foo, teach others how to do Foo".
Do you have any references supporting that interpretation?
When have we seen any real innovation? It is like we got to Word and everything stopped.
You make it sound as if MS Word was an improvement.
It probably was in some ways, but lots of people who used FrameMaker in the past
can tell you how much worse Word is, at least for long, technical documents.
If you are interested in binaries, then I would point you to Astraweb. They have great price plans.
Or maybe he'd prefer not to feed the kind of parasites who helped destroy Usenet.
I have very little respect for people who make others distribute and store their warez for them,
using resources intended for learning and discussions. They are on the same level as spammers.
Although RiscOS isn't technically an application, it did shatter the mythology that home computers could not multi-task or be user-friendly.
That was in 1988, according to the Wikipedia.
The Commodore Amiga was released in 1985 or so, with the extremely popular cheap home computer model A500 in 1987.
(No that the Amiga shattered any mythology, either. The mainstream preferred to pretend anything
but the IBM PC and MS-DOS was a toy, best ignored.)
I suppose if we re-compiled with debugging symbols, we might be able to use VS to figure out where the fault is, but we can't always compile everything in debug mode (even on Linux that significantly increases binary sizes and run times).
Who told you that? Compiling C or C++ code with gcc -g does *not* make it slower.
The binaries do get bigger (a lot bigger!), but that's symbol and line number tables which never even get loaded into memory.
Accept it, because the kind of standardized APIs that are needed are not going to happen with the attitudes that this community has.
1986
BYTE: Given that manufacturers haven't wanted to fund the project, who do you think will use the GNU system when it is done?
Stallman: I have no idea, but it is not an important question.
Are you suggesting that Stallman's attitude in 1984 destroyed GNU or something?
In 2009 everyone uses it in one way or another.
(Not that the things which drive Stallman are necessarily the same ones which drive Linux developers.)
Also, a bit more perspective:
look at the commercial Unixes of the 1990s. Were they irresponsible young Free Software worshippers? No.
Did they manage to come up with a standardized GUI? No. The closest was Motif and CDE, and they sucked.
Grandparent: "using std::vector::at and std::iterator to access it in c++, then c++ would be significantly slower"
Oh, I know - and I can think of a dozen similar ways to make the C++ version slower than the C version. But nobody with any sense would do that if they were trying to speed up the code as much as possible.
If you're thinking of vector::at() you're possibly right.
But a vector::iterator doesn't have to be slower than a pointer, and avoiding it for fear of
speed issues would be stupid.
I can imagine some C++-y things being slower (std::copy compared to memcpy, in some situations)
but not simple iterators.
In fact, when I ran the code below across a 200,000 element array/vector,
the std::vector version was 10% faster.
(Note that I didn't benchmark array indexing; I am so used to iterators that [begin, end)
is the style which feels natural to me even when I use raw pointers.)
int bencharray(int * const a, int * const b) { int val; for(int i = 0; i < 50000; ++i) { int * p = a; val = random(); while(p!=b) { *p++ = val++; } } return val; }
int bench(std::vector<int>& v) { const std::vector<int>::iterator a = v.begin(); const std::vector<int>::iterator b = v.end();
int val; for(int i = 0; i < 50000; ++i) { val = random(); std::vector<int>::iterator p = a; while(p!=b) { *p++ = val++; } } return val; }
So I still don't understand how that benchmarking guy (who knew C++ well!)
managed to make it three times slower than C.
We should probably ignore his results altogether, since his source code is lost.
The fact is, vector art isn't cheap. Not computationally, not memory wise.
Really? Why not? I would have thought it's just Bresenham and a bunch of other familiar algorithms
(splines, clipping, antialiasing and stuff) into a raster buffer.
("Cheap" is relative. I'm thinking "cheap" as in "insignificant load on a computer from this millenium";
I remember that my Amiga 500 wasn't all that good for rendering Postscript.)
We're talking 2D, non-animated, right?
it takes a bunch of libraries (XML parser, CSS parser, layout engine, etc)
You need a bloody XML parser to do vector graphics?
Or are you referring specifially to SVG now?
Frankly, I would put/bin/bash as first on the list.
My toolchain (ranked by degree of my dependency on the tool) is: bash, vim, exuberant ctags, GNU make, GNU diff, GNU grep, GNU find, GCC, man, git, perl, gdb, objdump.
nm(1) is pretty high on my list, otherwise they are pretty similar (s/vim/emacs/ though).
What's more interesting is that such lists are open-ended.
There's no IDE designer deciding what tools we should have and not have.
Also, the tools on *my* list do not conflict with yours.
You can use your tools and I can use mine, and we can build a piece of software together.
(Except we must agree on the building and version control parts.)
Few people can - and want - to go into details of how tool-chain really works. [...] I know many good developer who know about e.g. make only how to invoke it - "make all". Not more. Rest they do in e.g. Emacs. For Windows (or GUI development in general) it is very hard (if possible at all) to keep a track of all the details tool-chain does for you. And many people prefer to ignore the details - to concentrate on job at hand instead.
Those people aren't good developers.
The Makefile is part of the source code, just as the C (or whatever) sources.
There are no more justifications to ignore it than to ignore some random foo.c file.
(Of course, often it makes sense to avoid understanding all the source code, but the
Makefile is one of the key files.)
Actually, I don't really get your concept of tool-chain. It's so old-fashioned.
It's not something you study for a year and then become The Toolchain Expert.
You need to do something, you ask someone how, and then learn how to do it.
No need to learn things you don't have a use for!
The holywar "Emacs v. vi" from its inception revolved around precisely the nature of developer. Some developers like to know the details. Some developers prefer to ignore them and just press a button to achieve desired result. On side of "vi", one has to deal with more information. On side of "Emacs" one has to accept that some workflows would be impossible, since there might be no ready button for it. Side of "vi" is flexibility. Side of "Emacs" is conservatism.
I almost hope you are making this up as a trolling exercise.
I see no real difference betweeen Emacs and vi users these days,
and no flexibility/conservatism dichotomy either.
It's also the first time I've seen someone accusing Emacs of not being extensible...
more to the point: why does the brightest object in the solar system have nice shading effect to make it look spherical?
I accept that this photo has been certified legit, but that shading screams fake to me because the sun should only look like a flat disc. So the question I'm asking astronomers is to explain why the sun appears spherical instead of like a big flat bright disc?
I don't know *why*,
but that is indeed what the sun looks like if you watch it heavily filtered in a telescope,
or use a telescope to project it on a surface.
If you're using C++ and memcpy then you really do need to know what both you and the compiler are doing.
If you're using C++ and memcpy(), then you probably *don't* know what you're doing.
You should just copy your objects using =
(just like C users should,
although many seem stuck in the 1970s and insist on memcpy()ing anything larger than 32 bits)
or if it's sequences you're copying you should use std::copy which
unlike memcpy() is type safe and works on anything which can be iterated over.
Just to be clear, most of the movies that have been made from PKD's works are indeed based on his short stories, but that is far from all he wrote. A Scanner Darkly was a regular length book as is Flow My Tears.
Most of his later works were novels.
He basically stopped writing short stories, because he got paid better to write novels
(read: didn't have to physically starve).
I think the critique of Dick's characterization is off the mark; that just wasn't what he was *doing*. Dick wasn't writing a 19th century psychological novel; if you want that, go read someone Russian. But to attack Dick for his lack of characterization would be like doing so to Kafka or Pynchon.
And the same could be said about the grandparent's critique of 1950s--1960s SF in general.
Not that they were all doing what Dick did, but there are things which need to be written
about which are neither "real characterization" nor "Cool! My STAR CRUIZER runs on URANIUM!".
Given the lack of similarity between Next and The Golden Man, I was very surprised that they credited Dick at all.
I didn't know there was a movie based on that one.
What a bummer that would have been, if any of the elements of the actual story made it to the movie.
Just a bunch of depressed bureaucrats who know they're going to fail,
complain loudly that they are going to fail, and eventually fail.
What's next?
A movie based on that one where Jesus materializes in a spaceship, and eats
the protagonist's face?
Starring Jodie Foster?
I remember reading "We Can Remember It For You Wholesale" after having seen Total Recall and... well, I love PKD, and Total Recall is way more entertaining than WCRIFYW.
I disagree. Both are very cool, but in different ways.
I read the short story when I was like thirteen, and I still remembered it when I picked up
the short story collection twenty years later.
"Flow My Tears..." is amongst my favourites, and probably among the more cinematic, but like Three Stigmata of Palmer Eldritch, there's are all the druggy psychedelic passages that may not translate well.
I don't know about that... druggy passages can be good on film,
Case in point: Beavis and Butthead do America.
Slashdot Mirror
Who are you quoting? I can simply point to my dpkg -l listing, from at to zsh (alsa sucks and the others before at are kind of support packages). Free software which uses the traditional Unix user interfaces is usually superior to anything proprietary, if it even exists.
And the best known Kodachrome is Kodachrome 64 at "just" ISO 64, isn't it? Back in the late 1980s when I shot slides a lot, I tended to use ISO 200 film -- but I was painfully aware that Kodachrome 64 would have produced better colors and sharpness. I traded quality for convenience.
You're probably right, but 5--6 megs is a lot, too. On my system, the only binary larger than that is emacs (at 6.7 megs). (Oh, I know there are lots of other things which need disk space, but I can't be bothered to find out how to sort my dpkgs by install size.)
Not that any of this really concerns me. I don't let Gnome come anywhere near my three or four Debian systems. Nor KDE for that matter.
That paragraph scares me, because you suggest that there are workplaces where you're *not* supposed to look at anyone else's code. That would be a really stupid system.
In my experience, it's usually the "guest" (myself included) who is too reluctant to read it.
Do people really send patches around for review? I distrust fancy collaboration tools. All you need is the label/tag in the version control system and everything is there: the actual code and other files (e.g. user documentation) to review, and the checkin comments leading up to it.
Maybe the review comments should also go into version control, so what you eventually merge is (a) the code under review + (b) review comments pointing out what sucks + (c) the changes which eliminate the review comments and the (if the comments where valid) things they complained about.
Exactly. 911 calls would now be executed in a brand environment which most phones never enter. If you're lucky, the phone vendor has tested 911 calls, but it hasn't seen much real field testing. And dead people don't file bug reports ...
That sounds right, in a Michael-Ironside-in-Starship-Troopers kind of way. "If you can no longer do Foo, teach others how to do Foo". Do you have any references supporting that interpretation?
You make it sound as if MS Word was an improvement. It probably was in some ways, but lots of people who used FrameMaker in the past can tell you how much worse Word is, at least for long, technical documents.
Or maybe he'd prefer not to feed the kind of parasites who helped destroy Usenet. I have very little respect for people who make others distribute and store their warez for them, using resources intended for learning and discussions. They are on the same level as spammers.
That was in 1988, according to the Wikipedia. The Commodore Amiga was released in 1985 or so, with the extremely popular cheap home computer model A500 in 1987.
(No that the Amiga shattered any mythology, either. The mainstream preferred to pretend anything but the IBM PC and MS-DOS was a toy, best ignored.)
> for(std::list it=list.begin();it!=list.end();it++) {
> cout name }
You obfuscated the C++ version with pointers and a 'name' member. It should have gone
for(std::list it=list.begin(); it!=list.end(); ++it) {
cout *it "\n";
}
Still uglier than Python, but at least it's fast and type-safe.
Who told you that? Compiling C or C++ code with gcc -g does *not* make it slower. The binaries do get bigger (a lot bigger!), but that's symbol and line number tables which never even get loaded into memory.
Are you suggesting that Stallman's attitude in 1984 destroyed GNU or something? In 2009 everyone uses it in one way or another. (Not that the things which drive Stallman are necessarily the same ones which drive Linux developers.)
Also, a bit more perspective: look at the commercial Unixes of the 1990s. Were they irresponsible young Free Software worshippers? No. Did they manage to come up with a standardized GUI? No. The closest was Motif and CDE, and they sucked.
If you're thinking of vector::at() you're possibly right. But a vector::iterator doesn't have to be slower than a pointer, and avoiding it for fear of speed issues would be stupid. I can imagine some C++-y things being slower (std::copy compared to memcpy, in some situations) but not simple iterators.
In fact, when I ran the code below across a 200,000 element array/vector, the std::vector version was 10% faster. (Note that I didn't benchmark array indexing; I am so used to iterators that [begin, end) is the style which feels natural to me even when I use raw pointers.)
So I still don't understand how that benchmarking guy (who knew C++ well!) managed to make it three times slower than C. We should probably ignore his results altogether, since his source code is lost.
Really? Why not? I would have thought it's just Bresenham and a bunch of other familiar algorithms (splines, clipping, antialiasing and stuff) into a raster buffer. ("Cheap" is relative. I'm thinking "cheap" as in "insignificant load on a computer from this millenium"; I remember that my Amiga 500 wasn't all that good for rendering Postscript.) We're talking 2D, non-animated, right?
You need a bloody XML parser to do vector graphics? Or are you referring specifially to SVG now?
nm(1) is pretty high on my list, otherwise they are pretty similar (s/vim/emacs/ though).
What's more interesting is that such lists are open-ended. There's no IDE designer deciding what tools we should have and not have. Also, the tools on *my* list do not conflict with yours. You can use your tools and I can use mine, and we can build a piece of software together. (Except we must agree on the building and version control parts.)
No doubt that annoys small-minded people ...
Those people aren't good developers. The Makefile is part of the source code, just as the C (or whatever) sources. There are no more justifications to ignore it than to ignore some random foo.c file. (Of course, often it makes sense to avoid understanding all the source code, but the Makefile is one of the key files.)
Actually, I don't really get your concept of tool-chain. It's so old-fashioned. It's not something you study for a year and then become The Toolchain Expert. You need to do something, you ask someone how, and then learn how to do it. No need to learn things you don't have a use for!
I almost hope you are making this up as a trolling exercise. I see no real difference betweeen Emacs and vi users these days, and no flexibility/conservatism dichotomy either. It's also the first time I've seen someone accusing Emacs of not being extensible ...
Not meaningless. Potentially misleading, maybe (when a lot of code is optimized away or inlined). But profiling is always potentially misleading ...
I don't know *why*, but that is indeed what the sun looks like if you watch it heavily filtered in a telescope, or use a telescope to project it on a surface.
He's in the duo Gnarls Barkley, who got insane amounts of airplay with "Crazy" a few years ago. You have probably heard their songs.
If you're using C++ and memcpy(), then you probably *don't* know what you're doing. You should just copy your objects using = (just like C users should, although many seem stuck in the 1970s and insist on memcpy()ing anything larger than 32 bits) or if it's sequences you're copying you should use std::copy which unlike memcpy() is type safe and works on anything which can be iterated over.
Most of his later works were novels. He basically stopped writing short stories, because he got paid better to write novels (read: didn't have to physically starve).
And the same could be said about the grandparent's critique of 1950s--1960s SF in general. Not that they were all doing what Dick did, but there are things which need to be written about which are neither "real characterization" nor "Cool! My STAR CRUIZER runs on URANIUM!".
I didn't know there was a movie based on that one. What a bummer that would have been, if any of the elements of the actual story made it to the movie. Just a bunch of depressed bureaucrats who know they're going to fail, complain loudly that they are going to fail, and eventually fail.
What's next? A movie based on that one where Jesus materializes in a spaceship, and eats the protagonist's face? Starring Jodie Foster?
I disagree. Both are very cool, but in different ways. I read the short story when I was like thirteen, and I still remembered it when I picked up the short story collection twenty years later.
I don't know about that ... druggy passages can be good on film,
Case in point: Beavis and Butthead do America.