If you're going to be sarcastic and condescending, you might want to actually get your facts straight. KDE is not a window manager. KDE is a desktop environment. The window manager which comes with KDE is KWM.
Yes, I never "knew what was happening" when I pulled down a menu before. Now, with the help of shadows, I finally understand what's happening when I click on the pull down menu.
Install Python on their system and let them learn with it. It is an excellent learning language. Very clean syntax, and a lot of nice modules available for it.
Before you flame me, I'm a Perl programmer by trade, and I prefer Perl for a lot of tasks. I would, however, never, ever, ever recommend someone learn to program with Perl. It's cruel.
Score 0, flamebait? Why? Because I don't like seeing a character from one of my favorite book series being turned into a commercial for a giant media company?
Give me a break.
And no, I don't mean "big duh" as to why he's leaving. I mean "big duh" to "gee, the company really DOES own my code, after all?"
Working as a programmer is very, very simple. You work for a company. That company *pays* you to make things. The company owns the things you make.
This isn't even a case of AOL saying it owns something he made and distributed on his spare time. He wrote code and put it up for distribution on a web site owned by his employer, using a brand owned by his employer.
Very simple rule: if you don't want your employer to control your code, don't write the code at work and distribute it via work. If your employer has a ridiculous clause saying they own everything you write in your spare time as well, then either don't write anything for yourself, or find a new job.
I would be willing to bet that, under the employee agreements of anyone working at Nullsoft, that any code they create on the job is the exlusive property of AOL. If a Nullsoft employee, without authorization, wrote an application and put it up for distribution, AOL can say they did not have permission to do this, the code is copyright AOL, and the code was distributed illegally.
The fact that the code is GPL'd is irrelevant. None of you even know if anyone working at Nullsoft has the right to release GPL'd code in the first place.
It is a research project. They're doing it to see if they can do it. Creating a robot that cn play foosball is obviously an interesting technical challenge in a lot of ways. The researchers will learn a lot in the process.
"Hey look at this cool new bittorrent tool. People are illegally trading games and movies and mp3s with it. Here's a big list of sites where all the pirates exchange information for all of you!"
Brilliant.
Say goodbye to all of the bittorrent site you can find from this slashdot article. They won't last long now.
Maybe you should bone up on your reading comprehension skills before you attack people.
all applications have a structure like:
[appname]/[bin,lib,doc,conf]
Read the above a few times, please.
And if you are now going to suggest that the lib directories under each app will just be a symlink to/usr/lib, or something similiar... I fail to see how having a tangled mess of symlinks layered over a standard unix file layout is any sort of improvement.
"I have yet to find ONE good reason to maintain the "traditional" unix filesystem layout on a desktop machine (well, even server, but let's not go there)"
No matter what version of unix, or unix-like OS I log into at work, I already know the filesystem hierarchy, and I don't have to waste any time looking around in a bunch of random directories for the information I need. Once I learn the filesystem layout for any unix, I roughly know it for every unix.
"Does anybody install only the
binaries of an app, and not, say, it's libraries?? or it's docs?"
Yes. There are these things called "shared libraries". The nice thing about them is that, no matter how many apps are using them, I only have to install one copy them. If I put all the libraries for an application in a directory for the application, I'd have to install say, all the gtk libs, for every gtk application on my system.
"As for #1, when your primary interface to the OS is a GUI desktop,
having every piddly executable on your system in one directory doesn't
really confer any benefit."
First of all, please don't tell me what my primary interface to my operating system is. Secondly, if your primary interface is a GUI desktop, then it doesn't hurt to have all the apps under bin, either. Most users don't run applications by browsing to the specific app on the filesystem in a file manager. The run the applications from a menu, or an icon. This provides a virtual directory structure, that is abstract, that allows a GUI user to organize their applications as they want, without breaking the standard filesystem layout.
Any Perl programmers in the audience may wish to check out DBD::RAM. From the CPAN documentation:
"DBD::RAM allows you to import almost any type of Perl data structure into an in-memory table and then use DBI and SQL to access and modify it. It also allows direct access to almost any kind of file, supporting SQL manipulation of the file without converting the file out of its native format."
More information here
Slashdot Mirror
If you're going to be sarcastic and condescending, you might want to actually get your facts straight. KDE is not a window manager. KDE is a desktop environment. The window manager which comes with KDE is KWM.
Yes, I never "knew what was happening" when I pulled down a menu before. Now, with the help of shadows, I finally understand what's happening when I click on the pull down menu.
Will you all remember this when the next big blizzard game comes out? Or will you all just run to the store to buy it, just like Warcraft 3?
Install Python on their system and let them learn with it. It is an excellent learning language. Very clean syntax, and a lot of nice modules available for it. Before you flame me, I'm a Perl programmer by trade, and I prefer Perl for a lot of tasks. I would, however, never, ever, ever recommend someone learn to program with Perl. It's cruel.
Score 0, flamebait? Why? Because I don't like seeing a character from one of my favorite book series being turned into a commercial for a giant media company? Give me a break.
... to be able to watch one of Tolkien's timeless characters turned into a whore for MTV.
I wish they'd never made the damn movies.
Working as a programmer is very, very simple. You work for a company. That company *pays* you to make things. The company owns the things you make.
This isn't even a case of AOL saying it owns something he made and distributed on his spare time. He wrote code and put it up for distribution on a web site owned by his employer, using a brand owned by his employer.
Very simple rule: if you don't want your employer to control your code, don't write the code at work and distribute it via work. If your employer has a ridiculous clause saying they own everything you write in your spare time as well, then either don't write anything for yourself, or find a new job.
I would be willing to bet that, under the employee agreements of anyone working at Nullsoft, that any code they create on the job is the exlusive property of AOL. If a Nullsoft employee, without authorization, wrote an application and put it up for distribution, AOL can say they did not have permission to do this, the code is copyright AOL, and the code was distributed illegally. The fact that the code is GPL'd is irrelevant. None of you even know if anyone working at Nullsoft has the right to release GPL'd code in the first place.
It is a research project. They're doing it to see if they can do it. Creating a robot that cn play foosball is obviously an interesting technical challenge in a lot of ways. The researchers will learn a lot in the process.
In a press release today, the SCO corporation said, that if more people don't buy SCO Unix, they will kill a puppy.
"Hey look at this cool new bittorrent tool. People are illegally trading games and movies and mp3s with it. Here's a big list of sites where all the pirates exchange information for all of you!" Brilliant. Say goodbye to all of the bittorrent site you can find from this slashdot article. They won't last long now.
Are you posting anonymously because you are afraid that everyone will know that you are a PHP coder?
And the fact that PHP coders don't think that a total lack of namespaces is all that bad is why everyone thinks PHP coders are morons.
Maybe you should bone up on your reading comprehension skills before you attack people.
all applications have a structure like: [appname]/[bin,lib,doc,conf] Read the above a few times, please. And if you are now going to suggest that the lib directories under each app will just be a symlink toNo matter what version of unix, or unix-like OS I log into at work, I already know the filesystem hierarchy, and I don't have to waste any time looking around in a bunch of random directories for the information I need. Once I learn the filesystem layout for any unix, I roughly know it for every unix.
"Does anybody install only the binaries of an app, and not, say, it's libraries?? or it's docs?"Yes. There are these things called "shared libraries". The nice thing about them is that, no matter how many apps are using them, I only have to install one copy them. If I put all the libraries for an application in a directory for the application, I'd have to install say, all the gtk libs, for every gtk application on my system.
"As for #1, when your primary interface to the OS is a GUI desktop, having every piddly executable on your system in one directory doesn't really confer any benefit."First of all, please don't tell me what my primary interface to my operating system is. Secondly, if your primary interface is a GUI desktop, then it doesn't hurt to have all the apps under bin, either. Most users don't run applications by browsing to the specific app on the filesystem in a file manager. The run the applications from a menu, or an icon. This provides a virtual directory structure, that is abstract, that allows a GUI user to organize their applications as they want, without breaking the standard filesystem layout.
Any Perl programmers in the audience may wish to check out DBD::RAM. From the CPAN documentation: "DBD::RAM allows you to import almost any type of Perl data structure into an in-memory table and then use DBI and SQL to access and modify it. It also allows direct access to almost any kind of file, supporting SQL manipulation of the file without converting the file out of its native format." More information here