Ick. Learn to structure your programs well, and to write portable code, then you don't have to ship tons of convoluted autocrap with your sources.
The "just let automake take care" mindset is getting really annoying. There are already too many packages out there with an half-an-hour-./configure and shell scripts starting with #!/bin/bash. Duh.
Yeah, amazing how cross platform.NET is with one and a half implementation... Admittedly it runs fine on all current, frequently used non-embedded OSes that are not Unix based. I.e. Windows only, basically.
First of all,/usr should rather become/stuff_not_needed_before_system_in_multiuser_mode, and/var/stuff_that_might_change_so_you_cannot_mount_this_ partition_read_only, if you want to translate their current meaning;-).
And how, by any stretch of the imagination, is/etc less oddball than/settings? What universe do you live in? The directory name "etc" is an artifact of history, not a brilliant design plan. 1K of memory was expensive so the directory names were kept as short as possible. Now 1K is a rounding error. The reasons for "etc" no longer exist today. You might as well tell me that people should still hone their PDP-11 assembly skills before doing any programming in a high-level language.
I don't claim that/etc is a brilliant design choice. I wouldn't call it that if I were to design a new system from scratch. But I'm not, and neither is LSB. The problem is existing software that depends on/etc being called/etc (and be it by a default setting in config.h).
Your symlink proposal doesn't cut, IMHO. If LSB (that's what we are talking about, right?) would decide to recommend symlinking/etc to/settings or vice versa, users might become used to/settings over time. However, clever software developers would not, because, frankly, most Unix vendors are not that interested in the findings of the Linux standards base, so/etc would still be what works everywhere. And an updated POSIX standard seems unlikely, so you would have to live with this dualism virtually forever.
/etc ain't descriptive. It's the UNIX club's code word for/settings. They like code words. It's like a secret handshake. It maintains a feeling of superiority however obviously false that feeling may be.
I think it was the Unix haters handbook where I read an insightful article that argued that the naming conventions in Unix and C evolved with K&Rs ability to touch-type - it all started with "int" and "ls", later stuff like "locate" and "register" appeared...;-)
Well, it's mostly white with green with black text, also some parts of it have a grey background. Around it is a black border which on top contains a light-blue ad from Microsoft Small Business Solutions. Oh, and if you've been nice, it contains that neat moderation boxes.
Hah! I'd say, go with UTF-32! Or why not UTF-64 right from the start?!?
Seriously, AFAIK there is nothing you can encode as UTF-16 that you cannot encode with UTF-8 (one or the other might be more efficient in a given case, of course, but chances are that UTF-8 will win over all - it's unlikely that all Unix user commands will suddenly get names in sanskrit or elvish). Then again, I never cared much about character encodings. Care to enlighten me?
Standardizing on a Linux package format and library versions/locations/whatever would only be half the deal - you still wouldn't be able to release one binary that magically works on Linux/i386, Linux/Alpha, Linux/Sparc, Solaris/Sparc, Irix/Mips, NetBSD/Wristwatch etc. Yet, if you know a bit about Unix programming, chances are that your source code would compile and run just fine there. Think lots of potential customers!
What the world needs isn't something like a "standardized Linux package format", but something like autoconf that happens to be more of an actual solution and less of a problem on it's own. Portability rocks. Both for users and developers.
(BTW: That's one point of Open Source/Free Software/Whatever that is too often overlooked: Getting your programs as source code, regardless of the license, is friggin convenient! Binaries are inflexible - it might seem easier at first, but you run into the limitations really, really fast.
Non-uniformness annoys you? Why do you then want to break ages-old conventions like naming directories/etc and/opt, like about every other Unix-like system does?
Apple is the one using a non-standard scheme here. It doesn't matter for them too much, I guess, because they didn't expect the typical Mac user to have experience with other Unices, but that assumption isn't valid for Linux. The linuxisms introduced by sloppy coders (just search for '#!/bin/bash' in your favourite packages) are already enough of a PITA for people who happen to use a Unix-like operating system that is less hyped. If they would now come up with some oddball directory naming scheme, it would not do nothing but harm for anyone -- users who can't remember that config files live in/etc should in most cases not have to fiddle with them anyway - just give them a hard-to-misuse GUI or, better, a competent admin.
--
Why the @!$# can't I use entities like — when posting as HTML?!?
Common Lisp makes an excellent server-side tool, and is blazingly fast*, plus better OO than virtually anything else.
Agreed, CL seems to be the only sane language around, with all others essentially being (buggy) subsets of it.
However, for the type of work one would probably do with Tomcat, the point that there are a LOT of ready-to-use libraries for Java might me more important than the language itself - there just isn't as many CL code freely available.
Maybe Jython could serve as a compromise, integrating the Java APIs with a better subset of Common Lisp;-)
I actually think EMACS is the best all round (sp?) programming IDE available for UNIX,
EMACS is of course a very advanced text editor *operating system? heh* incorporating LISP
Emacs, my misguided friend, is neither an IDE nor an operating system. It's hard to explain what it is exactly, scince there is no other piece of software that really is comparable, but I think comparing it to Gnome or KDE would be more appropriate than to Linux or vi in that it features a consistent, powerful environment for all your computing tasks, from editing text to reading mail, browsing the web or playing tetris.
No surprise, given that, as we all know, every programming language is essentialy a subset of Common Lisp, and Emacs is based on one of the best of those. Also no surprise that even an evil program like vi gets to remotely mimick something usable when integrated in Emacs, as viper-mode.el shows.
I strongly believe in the way UNIX is composed, VIM is a smaller block than EMACS
vi is of course a more UNIXy program than Emacs. Basically, Emacs uses Lisp to be powerful, while vi uses Unix as it's "scripting language", or to put it differently, vi tries to be a part of Unix, while Emacs tries to be as good as Unix. Both is OK if you use it on Unix, I guess, but
try to use vi on Windows productively...
This comparison is insane. It is like arguing whether Excel or Unicode is better for dynamic web pages.
The point is,.doc sucks (because Word does). It doesn't carry any semantics, basically you cannot do anything interesting with a.doc except printing or reading it. On the other hand, while it is all about presentation, it is bad at that - just use another printer driver, and this presentation changes all along.
Nothing stops you from implementing an as braindead format using XML. That is exactly what OpenOffice.org did. Still, it may be braindead, but at least it might be easier to parse.
The One True Way for document storage is using semantic markup. Of course, it's not something widely popular in the marketing department, but that might be due to the lack of meaning in the documents they prouce.
Every time a subject like this comes up on Slashdot, I try to promote a project that we think has the solution for Linux on the desktop.
We noticed.
Usually, when you say the same thing over and over, and nobody seems to react, it's time to think about stopping to annoy everyone. You could try to post interesting articles, maybe even On-Topic ones, instead.
I honestly hope that this won't end up in a flamewar, but I have a question
to all gentoo-users that I wanted to ask for quite some time now.
If the outstanding feature of gentoo is its BSD-like package management,
why don't you use BSD in the first place? For example, FreeBSDs ports tree
is quite mature, huge (~7,300 ports last time I checked, and there isn't
the distinction between libfoo and libfoo-devel common in the Linux world)
and comfortable, especially with the help of portupgrade and friends.
I my understanding (as a BSD user coming from Linux) the cool thing about
ports/pkgsrc/emerge is the elegance through simplicity. You just know
whats going on on your system. (Try that with Windows;) You have a chance
to tweak things, and - important if you, like me, use some rather obscure
packages noone else would ever think of including in a distribution - it's
braindead easy to create a port/pkgsrc/whatever-gentoo-calls-it yourself.
IMHO, this elegance is found in every place of BSD systems. For example,
the kernel config file is, well, just that - a simple, documented file. No
make menuconfig. No xconfig. No applying loads of cool patch sets found
anywhere on the net.
So, for someone who likes ports/pkgsrc/emerge, I'd say a BSD ist a cool
system to use it on;-). However, I only read comparisons between Gentoo
and other Linux distros, not between Gentoo and the BSDs. Could
anybody using both please share his/her opinions about the relative merits?
If I could just install any piece of Windows software by typing "make install"
instead of having to use useless installers, I would probably use it more often,
too.
Especially if that would include that I could tweak the installed software
to my pleasure (and I'm not talking about./configure, I'm talking about vi),
or just installing it without having to start a GUI. But I guess Windows
just isn't user-friendly enough.
Hint: There are quite a lot of kinds of users, and not a single way to
please them all.
Not to mention that compilers are sexy, but I guess you have to be a geek
to understand;-)
Slashdot Mirror
The "just let automake take care" mindset is getting really annoying. There are already too many packages out there with an half-an-hour-./configure and shell scripts starting with #!/bin/bash. Duh.
On PPC it's even easier: If the web site of the FreeBSD/PPC project isn't outdated, it won't get as far as multi-user mode anyway.
Except that you don't have to pay for a Solaris/Sparc license.
Yeah, amazing how cross platform .NET is with one and a half implementation... Admittedly it runs fine on all current, frequently used non-embedded OSes that are not Unix based. I.e. Windows only, basically.
I don't claim that /etc is a brilliant design choice. I wouldn't call it that if I were to design a new system from scratch. But I'm not, and neither is LSB. The problem is existing software that depends on /etc being called /etc (and be it by a default setting in config.h).
Your symlink proposal doesn't cut, IMHO. If LSB (that's what we are talking about, right?) would decide to recommend symlinking /etc to /settings or vice versa, users might become used to /settings over time. However, clever software developers would not, because, frankly, most Unix vendors are not that interested in the findings of the Linux standards base, so /etc would still be what works everywhere. And an updated POSIX standard seems unlikely, so you would have to live with this dualism virtually forever.
I think it was the Unix haters handbook where I read an insightful article that argued that the naming conventions in Unix and C evolved with K&Rs ability to touch-type - it all started with "int" and "ls", later stuff like "locate" and "register" appeared... ;-)
Well, it's mostly white with green with black text, also some parts of it have a grey background. Around it is a black border which on top contains a light-blue ad from Microsoft Small Business Solutions. Oh, and if you've been nice, it contains that neat moderation boxes.
Seriously, AFAIK there is nothing you can encode as UTF-16 that you cannot encode with UTF-8 (one or the other might be more efficient in a given case, of course, but chances are that UTF-8 will win over all - it's unlikely that all Unix user commands will suddenly get names in sanskrit or elvish). Then again, I never cared much about character encodings. Care to enlighten me?
Standardizing on a Linux package format and library versions/locations/whatever would only be half the deal - you still wouldn't be able to release one binary that magically works on Linux/i386, Linux/Alpha, Linux/Sparc, Solaris/Sparc, Irix/Mips, NetBSD/Wristwatch etc. Yet, if you know a bit about Unix programming, chances are that your source code would compile and run just fine there. Think lots of potential customers!
What the world needs isn't something like a "standardized Linux package format", but something like autoconf that happens to be more of an actual solution and less of a problem on it's own. Portability rocks. Both for users and developers.
(BTW: That's one point of Open Source/Free Software/Whatever that is too often overlooked: Getting your programs as source code, regardless of the license, is friggin convenient! Binaries are inflexible - it might seem easier at first, but you run into the limitations really, really fast.
Non-uniformness annoys you? Why do you then want to break ages-old conventions like naming directories /etc and /opt, like about every other Unix-like system does?
Apple is the one using a non-standard scheme here. It doesn't matter for them too much, I guess, because they didn't expect the typical Mac user to have experience with other Unices, but that assumption isn't valid for Linux. The linuxisms introduced by sloppy coders (just search for '#!/bin/bash' in your favourite packages) are already enough of a PITA for people who happen to use a Unix-like operating system that is less hyped. If they would now come up with some oddball directory naming scheme, it would not do nothing but harm for anyone -- users who can't remember that config files live in /etc should in most cases not have to fiddle with them anyway - just give them a hard-to-misuse GUI or, better, a competent admin.
-- Why the @!$# can't I use entities like — when posting as HTML?!?# emerge rsync
# cvsup /etc/cvsupfile
To install GNOME:
# emerge gnome
# portinstall gnome
To update all of your packages to new versions:
# emerge -u world
# portupgrade -a
To remove all of the *old* versions of the packages updated by the last command, since they are protected until "cleaned" out:
# emerge -c world
Not sure what this does, but looks a litte like portsclean.
To forcibly remove a package:
# emerge -C $PACKAGE_NAME
pkg_deinstall -f $PACKAGE_NAME
To "pretend" you're running a given command:
# emerge -p$ADDITIONAL_FLAGS $PACKAGE_NAME
$ANY_COMMAND -n $OTHER_ARGS
I guess, for me emerge won't be the reason to switch from FreeBSD. (Nor the others you mentioned.) :-)
Exactly. Windows users aren't used to power and structure, so it's best to hide it.
Still gets better: NVidia drivers are on the way, too...
PHPs XML-support is still weak. Then again, it's a good match with the rest of this half-baked language.
Sure. I meant to imply that Python, as a language, is more "lispy" than Java, not that it is Common Lisp.
None of which seem to be CL, unfortunatly
However, for the type of work one would probably do with Tomcat, the point that there are a LOT of ready-to-use libraries for Java might me more important than the language itself - there just isn't as many CL code freely available.
Maybe Jython could serve as a compromise, integrating the Java APIs with a better subset of Common Lisp ;-)
No surprise, given that, as we all know, every programming language is essentialy a subset of Common Lisp, and Emacs is based on one of the best of those. Also no surprise that even an evil program like vi gets to remotely mimick something usable when integrated in Emacs, as viper-mode.el shows.
vi is of course a more UNIXy program than Emacs. Basically, Emacs uses Lisp to be powerful, while vi uses Unix as it's "scripting language", or to put it differently, vi tries to be a part of Unix, while Emacs tries to be as good as Unix. Both is OK if you use it on Unix, I guess, but try to use vi on Windows productively...The point is, .doc sucks (because Word does). It doesn't carry any semantics, basically you cannot do anything interesting with a .doc except printing or reading it. On the other hand, while it is all about presentation, it is bad at that - just use another printer driver, and this presentation changes all along.
Nothing stops you from implementing an as braindead format using XML. That is exactly what OpenOffice.org did. Still, it may be braindead, but at least it might be easier to parse.
The One True Way for document storage is using semantic markup. Of course, it's not something widely popular in the marketing department, but that might be due to the lack of meaning in the documents they prouce.
One nice project is TrustedBSD, parts of which will appear in FreeBSD 5.0.
We noticed.
Usually, when you say the same thing over and over, and nobody seems to react, it's time to think about stopping to annoy everyone. You could try to post interesting articles, maybe even On-Topic ones, instead.
Um, what "move"? SAP DB is GPLed for years. It isn't the only once-commercial-now-free (or even Free?) database either, check out Interbase.
How about asking your significant other?
It's called "make".
If the outstanding feature of gentoo is its BSD-like package management, why don't you use BSD in the first place? For example, FreeBSDs ports tree is quite mature, huge (~7,300 ports last time I checked, and there isn't the distinction between libfoo and libfoo-devel common in the Linux world) and comfortable, especially with the help of portupgrade and friends.
I my understanding (as a BSD user coming from Linux) the cool thing about ports/pkgsrc/emerge is the elegance through simplicity. You just know whats going on on your system. (Try that with Windows ;) You have a chance
to tweak things, and - important if you, like me, use some rather obscure
packages noone else would ever think of including in a distribution - it's
braindead easy to create a port/pkgsrc/whatever-gentoo-calls-it yourself.
IMHO, this elegance is found in every place of BSD systems. For example, the kernel config file is, well, just that - a simple, documented file. No make menuconfig. No xconfig. No applying loads of cool patch sets found anywhere on the net.
So, for someone who likes ports/pkgsrc/emerge, I'd say a BSD ist a cool system to use it on ;-). However, I only read comparisons between Gentoo
and other Linux distros, not between Gentoo and the BSDs. Could
anybody using both please share his/her opinions about the relative merits?
Especially if that would include that I could tweak the installed software to my pleasure (and I'm not talking about ./configure, I'm talking about vi),
or just installing it without having to start a GUI. But I guess Windows
just isn't user-friendly enough.
Hint: There are quite a lot of kinds of users, and not a single way to please them all.
Not to mention that compilers are sexy, but I guess you have to be a geek to understand ;-)