GIF, JPG, and PNG do everything I need -- why a new image format?
Well, we were supposed to migrate to JPEG2000 a few years ago.
That hasn't happened yet, for some reason.
Is there even a free libjpeg-like C library for it?
*digs around in/var/lib/dpkg/*
Oh yes. libjasper.
But the only major software which depends on it seems to be ImageMagick.
Second, Java isn't really a very good language. From where I sit, it's basically C++ running in a VM with the syntax cleaned up.
Really?
From where I sit, it's a very different language
with a superficially similar syntax.
No control over object lifetimes (RAII etc).
No generic programming (until recently, I'm told).
A complete-ish standard library, but
no compatibiliy with existing C APIs.
Encourages more use of inheritance and polymorphism;
discourages creation of tiny user-defined types.
And I say that as a full-time Java programmer for 10 years. I know this language intimately and I'm less impressed than ever.
C++-alike isn't the only way to do an OO programming language.
Agreed. And with languages like Python and Ruby being popular,
that's easier to see today than it was back in 1996
(I never learned Smalltalk, or Eiffel, or ADA...)
There were a handful of editors installed, and people
used whatever they found useful.
Personally, I made a bad choice and stuck with xedit
(X11's equivalent of Windows' Nodepad).
The professors/assistants couldn't care less
-- as long as I had a Makefile so they could build and run my code.
That said, you might want to make sure Idle or Eclipse or whatever
is installed, and mention it in the intro to the exercises.
Re:Not unique to open source
on
The CVS Cop-Out
·
· Score: 1
The problem with distributing software as source, even with an automated process, is that it depends on the user having certain libraries installed, with development headers, and also a compiler.
That's the same problem as distributing it in binary form.
That, too, depends on the user having certain things installed.
The only extra problem I can see is if the software is closed-source.
Plus extra disk space needed for header files and a compiler.
You can't always have your cake and eat it too. How about a compromise? Only open-source where possible, but free as in beer is OK if there is no better open-source alternative.
Yes. Fortunately, there's C++, Python and various other languages...
This would allow people to use a mostly free OS, but still use quality closed-source yet free as in beer software like Java.
Not unreasonable in general (I use Opera with that excuse)
but it's a more serious decision when that software is the basis
of many other programs, like a Java environment is.
BSD-licenced things and the like. "Free Software" includes only licences with the "copyleft"/"viral" restriction.
No it doesn't.
Have a look at
this list.
The Gnu project defines the BSD license as a
"GPL-Compatible, Free Software License", which is the
category they like the most (apart from the GPL, that is).
I've been workign with java for abotu 7-8 years, and I'm not knowledgable in c++, [...]
No, because if you were...
As for java, what I've found (from talking to c/c++ developers)
... you would know if you had talked to C programmers
or C++ programmers. They are not the same. Good C is as dissimilar
to good C++ as good Java code is.
[Tell us again] how it's no big deal when your European governments retain data on you because you know that they'd never misuse it.
Who said it wasn't a big deal?
Of course it is.
But at least I have power over my own government
(and to some small extent, over the EU).
If G. W. Bush wants to put me in one of his camps,
I cannot vote him out of office...
once upon a time, there were these things called "newsgroups"...
No, no, no.
Didn't you read the article?
Newsgroups and List Serves (sic!) are a "hack fixes"
which "rely on the Email Inbox to send and receive data".
More absurdities follow further down in the article,
but you can stop reading there. It's near the top.
Isn't this the same kind of actions that open source advocates condemn, when Microsoft and friends use it ?
You seem to assume that because it's on Slashdot,
Slashdot and its readers think it's a good idea.
I don't believe that's the case.
It's a stupid idea, and it's against ideas that are more
important than open source.
It's against the idea that the network protocols should be
client-neutral, and that graceful degradation should take place
when you use a client that (like IE) sucks.
Focus on the data first, then the program logic.
The data format, the license and the means of creation and distribution.
You mention open source. What about the lyrics themselves?
If you are the single provider of that CD or DVD,
I don't care if the programs are open source or not.
All I care about is that the data is in an open format so
I can code against it myself. Closed-format content is useless to me.
I would say use Java. That was you don't have to recompile the application for every architecture.
Yes, saving a few milliseconds of CPU time, once, is important.
Seriously, if Java has any major benefits, that you don't have
to compile it isn't one of them.
Or at least it wouldn't be one if all computers came with a C compiler.
Also, Java isn't the only programming language with this property.
Python, Ruby, Perl, Tcl... the only popular languages which normally
need a compiler are C and C++.
I remember using X Windows in 1989. There was a company that used to sell greyscale X displays (Wyse? I'm not sure) long before 1992.
Yeah, but Sun invented NFS way before 1992, too.
And Unix workstations, networked together, in general --
if it wasn't their idea, they were certainly successful in that area
before 1992.
I'm not sure what good things Sun has done after 1992,
but they and McNealy at least deserve credit for the things
they did before that.
Yes, it is true that the answers to your questions are out there...Linux does have copious documentation. But the fact of the matter is that a simple answer to a simple question can do much more than save the newbie hours of combing through MAN pages...it can also foster the sense of community that is the very lifeblood of Linux.
You seem to view time spent combing through man pages
as wasted time.
I see it as time well spent:
learning the thing you were looking for,
learning other things related to it, and (important!)
learning to search for information.
That's, I think, one of the main reasons Unix users and
newbies become frustrated with each other.
The Unix users learned by RTFM and experimenting, and know
that serving ready solutions on a plate doesn't really
help the newbies solve the second, third,... problem they'll
inevitably have.
Related to this,
sometimes I think humans are beginning to lose the ability
to understand written text. I see otherwise intelligent people
losing concentration somewhere in the first paragraph of a one-page mail,
instead walking over and forcing me to basically recreate it,
orally. And I'm good at technical documentation.
In the future, noone will read a man page unless
it's tattooed on Britney Spear's butt.
What's funny is that the varied documentation methods in Linux is what infuriates me. As an old Unix-head, I think stuff should be in man pages. I hate the method of --help and/usr/share/doc/*. The OpenBSD guys may be extremely rigid, but they got it right with man
So does Debian. Some Linux distributions tolerate
poor man pages, some don't.
Personally, I don't touch software which doesn't have
a real man page.
Generally architecture changes, compiler version changes, break code on large projects. Over a million lines of code, any tiny little difference in the platform that the original developers didn't think to account for will come up *somewhere*. A good example of this is if you are dumping data structures to disk or network and write a size_t variable. Suddenly, you can no longer communicate between 32 bit and 64 bit versions of your software.
In general, I agree.
But the example is not a good one.
Dumping data structures to disk (or network)
should be a sacking offense.
I mean, this was well known to be a bad idea back in the 1970s!
My latest C project is an embedded avr system, where this is of course very important. The solution has been to make a header file with a bunch of typedefs in it like:
typedef unsigned char uint8;
typedef unsigned short uint16;
And so forth. Then I exclusively use the new types. If I need to compile to another platform, I just need to change the portable.h file.
Two comments:
Get yourself a compiler/stdlib with implements the
official C99 known size types:
uint8_t, uint16_t and so on.
Or have fun when you find you have to integrate your software with
someone elses, which uses u8, UBYTE, UCHAR, u_int8 or one
of the gazillion non-standard naming schemes I've seen for the same thing.
IMHO, you should use uint16_t and friends rarely, when you really need to for memory usage reasons, or possibly try to
enforce some special memory layout on structs.
It creates a lot of silent type conversions, which might have
hard-to-detect bugs. It forces type conversions whenever you
interface to the standard library or other people's APIs.
Look at the Linux kernel - extremely portable even though
almost all scalar variables are plain char, int or long.
I personally stick to sudo. The main reason why is to protect me from myself, more than anyone. Because I have to prefix the command with sudo, it serves as a 'mental brake' to slow down my typing, and double check what I type before I run it.
The '#' at the end of the prompt is my mental brake.
An example from one of my previous rants on this topic: "You can use the leviathan forces of attention and enthusiasm that are swirling around Web 2.0 these days as a powerful enabler to make something important and exciting happen in your organization."
[...] The sentence essentially boils down to a simple statement: You can use new technology as an opportunity to improve the operation of your business. I think most would agree this is an obvious, uninteresting statement [...]
Actually, I read it as "if you are ruthless,
you can exploit the hype around Web 2.0
to rise on the corporate ladder". Seriously.
If my task can be accomplished without a full-screen interface,
then I look for plain command-line software first.
If that doesn't help, I look at the full-screen terminal
applications (which can and should have screenshots), and
as a last resort, the GUI applications.
For non-visual software, the man page is a good indication of
quality. A sensible set of command-line options, correct grammar,
formatting et cetera probably means the program doesn't suck.
I note, with satisfaction, that you fail to mention any
specific benefits of using Subversion, over CVS.
[reordered]
There might actually be changes in two files that are related that neither cvs nor rcs is capable of keeping track off.
And SVN would do that better CVS, in some magical way?
I cannot see how.
If you have to rack out of a change, you either have a tag
or a known good date.
In either case, you'd 'cvs diff' against it, review the changes,
then revert all of them or cherry-pick.
Both tools can do that (and probably RCS too, with some scripting).
1) It seems to me, from using version control and watching others
use it, that there is no substitute for understanding.
Fancy GUIs help to some extent, but to really use
revision control, you have to be willing to think, to learn,
and to adapt the way you work.
(Is that is the same as being "a techie"? Perhaps.)
For images, video and other non-text data,
I suspect that it doesn't matter if you use Subversion's
"superior" support for binary data or CVS's "inferior" one.
I believe you will have problems, no matter what --
concepts like branching and merging are meaningless for those.
Possibly there are dedicated tools for such things.
Slashdot Mirror
Well, we were supposed to migrate to JPEG2000 a few years ago. That hasn't happened yet, for some reason. Is there even a free libjpeg-like C library for it?
*digs around in /var/lib/dpkg/*
Oh yes. libjasper. But the only major software which depends on it seems to be ImageMagick.
Really? From where I sit, it's a very different language with a superficially similar syntax. No control over object lifetimes (RAII etc). No generic programming (until recently, I'm told). A complete-ish standard library, but no compatibiliy with existing C APIs. Encourages more use of inheritance and polymorphism; discourages creation of tiny user-defined types.
And I say that as a full-time Java programmer for 10 years. I know this language intimately and I'm less impressed than ever. C++-alike isn't the only way to do an OO programming language.
Agreed. And with languages like Python and Ruby being popular, that's easier to see today than it was back in 1996 (I never learned Smalltalk, or Eiffel, or ADA ...)
There's The (Not So) Short Guide to LaTeX2e, I think it's called. It's adequate for basic usage.
There were a handful of editors installed, and people used whatever they found useful. Personally, I made a bad choice and stuck with xedit (X11's equivalent of Windows' Nodepad).
The professors/assistants couldn't care less -- as long as I had a Makefile so they could build and run my code.
That said, you might want to make sure Idle or Eclipse or whatever is installed, and mention it in the intro to the exercises.
That's the same problem as distributing it in binary form. That, too, depends on the user having certain things installed.
The only extra problem I can see is if the software is closed-source. Plus extra disk space needed for header files and a compiler.
Yes. Fortunately, there's C++, Python and various other languages ...
This would allow people to use a mostly free OS, but still use quality closed-source yet free as in beer software like Java.
Not unreasonable in general (I use Opera with that excuse) but it's a more serious decision when that software is the basis of many other programs, like a Java environment is.
No it doesn't. Have a look at this list. The Gnu project defines the BSD license as a "GPL-Compatible, Free Software License", which is the category they like the most (apart from the GPL, that is).
No, because if you were ...
As for java, what I've found (from talking to c/c++ developers)
... you would know if you had talked to C programmers or C++ programmers. They are not the same. Good C is as dissimilar to good C++ as good Java code is.
Who said it wasn't a big deal? Of course it is.
But at least I have power over my own government (and to some small extent, over the EU). If G. W. Bush wants to put me in one of his camps, I cannot vote him out of office ...
No, no, no. Didn't you read the article? Newsgroups and List Serves (sic!) are a "hack fixes" which "rely on the Email Inbox to send and receive data".
More absurdities follow further down in the article, but you can stop reading there. It's near the top.
You seem to assume that because it's on Slashdot, Slashdot and its readers think it's a good idea. I don't believe that's the case.
It's a stupid idea, and it's against ideas that are more important than open source. It's against the idea that the network protocols should be client-neutral, and that graceful degradation should take place when you use a client that (like IE) sucks.
It's stupid, and it won't work.
You mention open source. What about the lyrics themselves? If you are the single provider of that CD or DVD, I don't care if the programs are open source or not. All I care about is that the data is in an open format so I can code against it myself. Closed-format content is useless to me.
Yes, saving a few milliseconds of CPU time, once, is important.
Seriously, if Java has any major benefits, that you don't have to compile it isn't one of them. Or at least it wouldn't be one if all computers came with a C compiler.
Also, Java isn't the only programming language with this property. Python, Ruby, Perl, Tcl ... the only popular languages which normally
need a compiler are C and C++.
Not very surprising, since the Internet was developed long before Linux ...
Yeah, but Sun invented NFS way before 1992, too. And Unix workstations, networked together, in general -- if it wasn't their idea, they were certainly successful in that area before 1992.
I'm not sure what good things Sun has done after 1992, but they and McNealy at least deserve credit for the things they did before that.
You seem to view time spent combing through man pages as wasted time. I see it as time well spent: learning the thing you were looking for, learning other things related to it, and (important!) learning to search for information.
That's, I think, one of the main reasons Unix users and newbies become frustrated with each other. The Unix users learned by RTFM and experimenting, and know that serving ready solutions on a plate doesn't really help the newbies solve the second, third, ... problem they'll
inevitably have.
Related to this, sometimes I think humans are beginning to lose the ability to understand written text. I see otherwise intelligent people losing concentration somewhere in the first paragraph of a one-page mail, instead walking over and forcing me to basically recreate it, orally. And I'm good at technical documentation.
In the future, noone will read a man page unless it's tattooed on Britney Spear's butt.
So does Debian. Some Linux distributions tolerate poor man pages, some don't.
Personally, I don't touch software which doesn't have a real man page.
In general, I agree. But the example is not a good one. Dumping data structures to disk (or network) should be a sacking offense. I mean, this was well known to be a bad idea back in the 1970s!
typedef unsigned char uint8; typedef unsigned short uint16;
And so forth. Then I exclusively use the new types. If I need to compile to another platform, I just need to change the portable.h file.
Two comments:
Get yourself a compiler/stdlib with implements the official C99 known size types: uint8_t, uint16_t and so on. Or have fun when you find you have to integrate your software with someone elses, which uses u8, UBYTE, UCHAR, u_int8 or one of the gazillion non-standard naming schemes I've seen for the same thing.
IMHO, you should use uint16_t and friends rarely, when you really need to for memory usage reasons, or possibly try to enforce some special memory layout on structs. It creates a lot of silent type conversions, which might have hard-to-detect bugs. It forces type conversions whenever you interface to the standard library or other people's APIs. Look at the Linux kernel - extremely portable even though almost all scalar variables are plain char, int or long.
The '#' at the end of the prompt is my mental brake.
Actually, I read it as "if you are ruthless, you can exploit the hype around Web 2.0 to rise on the corporate ladder". Seriously.
If that doesn't help, I look at the full-screen terminal applications (which can and should have screenshots), and as a last resort, the GUI applications.
For non-visual software, the man page is a good indication of quality. A sensible set of command-line options, correct grammar, formatting et cetera probably means the program doesn't suck.
Yes, of course! Once again, XML saves the day! (And cures world hunger.)
I note, with satisfaction, that you fail to mention any specific benefits of using Subversion, over CVS.
[reordered] There might actually be changes in two files that are related that neither cvs nor rcs is capable of keeping track off.
And SVN would do that better CVS, in some magical way? I cannot see how. If you have to rack out of a change, you either have a tag or a known good date. In either case, you'd 'cvs diff' against it, review the changes, then revert all of them or cherry-pick. Both tools can do that (and probably RCS too, with some scripting).
For images, video and other non-text data, I suspect that it doesn't matter if you use Subversion's "superior" support for binary data or CVS's "inferior" one. I believe you will have problems, no matter what -- concepts like branching and merging are meaningless for those. Possibly there are dedicated tools for such things.