The user is still going to have to look for the files that resolve those dependencies. So I run galeon after installing it with Slackware and find it needed Mozilla - do you think I'd have been better off if the package manager, rather than the app - whose dependency can be resolved in a myriad of different ways - had refused to install it demanding a particular package be installed?
Yes!
manages packages can be described as being anything other than a package manager.
By not managing them to an acceptible standard.
(insert obligatory response to rather uncreative troll label here)
The wheel hasn't changed significantly over the years in terms of the base concepts behind it. Is this a good thing or a bad thing.
Its postive:
* Unix is easily the most reliable popular desktop, or server Operating System. Uptimes can and have been measured in years
* Modern Unix (of which Linux is the standard, but keep that low for now) is open, uses documented APIs, and provides users with great choice and flexibility as to how their machines work
* I've got high standard, and the ability to reconfigure a machine for say to day maintenace tasks without rebooting is in my opinion a standard part of any real server OS.
* Despite what most Slashdotters think, a modern Unix machine is capable of being used and administered entirely through its GUI or via the scripting-happy command line.
* Root sucks or rather, relying on one particular account to be the sole administrator sucks, and this si what most Unixes do. That stems from another problem
* RWX permissions suck. There's good replacements that work well and are just as easy to administer, but Linux, most BSDs, and many proprietary Unixes still use dodgy permissions which weren't desgned for security. Not being able to have any kind of fine grained control over who has access to a file sucks.
* lack of standardization hurts the platform. GNOME versus KDE hurts by dividing effort more than it helps by providing competition.A GNOME app under KDE still feels like...a GNOME app under KDE. Red Carpet is a brilliant ap but it acts differently from all the other KDE apps on my desktop. That really sucks. Standardization will hurt lots. The LSB settled on the RPM packaging system, told distros not to put things in/opt, and said init scripts must live in/etc/init.d. Some distros who had minor things to change have modified the way they are, but expect screaming when someone dare suggests the non-RPM distros convert.
A while back I was going through three-year-old modem logs looking for records of someone dialing in (billing dispute): grep for the UID, piped to awk to add up the time online, convert it to hours and print it out, piped to sendmail to mail it to the billing dept...
You can't do that with in WIMP environments, God bless 'em
Why not? Most GUI environments have had scripting capabilities to do this for a while, Windows has been able to do this task for around for years, and I'm sure Apple scripting language (not sure of its name - Applescript sounds obvious) can do it too.
What's Unix specific about it? Scripting rocks, but its hardly unique.
Where? I've yet to see you show ANYONE as agreeing with your definition.
I've explained why this is the case earlier. Use defines definition. This seems to elude you.
So presumably this now means your barrier to entry has changed and all packaging systems must not only check dependencies - but resolve them too?
No. And I don't follow your logic.
In any case, you've totally avoided answering the point. I've whittled down the list of "package managers" each time by finding a feature that is in all those left save one.
Really? Omigod! And you've missed the point: I've refuted your argument save for slackware. More importantly: the only `feature' which is based on making a system stabler, rather than saving time for administrators, is dependency checking.
To put it another way, every single Linux distribution out there has a package management system to ensure that it's easy to install, track, uninstall, and upgrade, components of the system in a modular way.
Again, making sure what's installed on the system WORKS is a big part of that.
If you're arguing that Slackware lacks such a system, and you agree that every other Linux distribution has a package management system as part of it, do you thus believe that Slackware is not a Linux distribution?
That's not that difficult to say. Distributions which install software in/opt, can't install RPM packages, or put things in unusual places can be defined as not being Linux in that they do not meet the Linux Standard Base. They're just OS which use the Linux kernel. Controversial now, but it will be pretty common in five years time.
Or did you mean "You're"
Oh God. Too much time online and too much anger in my mind when I wrote that.
Spelling flames are usually lame
Yeah they are, but mea culpa.
So you agree then that it is a packaging management system and your claims that it isn't are merely insults for the sake of criticism rather than intended to be taken seriously?
No I don't. Quoting me saying Slackware is a `piece of technology' and using this as evidence I believe Slackware is a packaging system is just as bad an abuse of logic as my own abuse of English (you're / your) above.
You're defining package management as meaning more than the management of packages.
No, I've said keeping a system stable is part of management. Ignoring that and not responding to it is `just dumb'.
As for the personal attacks, I started out as merely disagreeing with you, as the other posters did. You chose to turn that into a stream of insults.
I never insulted anyone until being told by someone"Terribly sorry to ruin your soapbox. Do go on though, it was *almost* interesting." . You chimed in with your own chilidsh little imitative misquote. And you dare call *me a troll?
What exactly is it about Slackware package management that riles you this way?
Nothing. I'm just cautious about anything which harms the integrity of a system. Finding out the installed software requires another piece of software post install is simply poor engineering and bad for the integrity of the installed system. As I've said before: there's nothing majorly wrong with Slackware's software installation system if that's all you want or need, its just not a packaging system.
I mean, for crying out loud, you've started an entire subthread here about how upset you are
I'm not upset, or at least I wasn't until your annoying little `let me see...you think all Slackware users are Pterodactyls!!!'-type manipulations of my words.
I've riled the feathers of people who like a piece of technology too much to acknowledge it has obvious faults. I don't expect you to agree with me, but I do expect some respect and for you to actually read my postings (which you have not) before you (Mister AC) choose to label *me* as a troll.
We both agree that a package management should...well... manage packages. I have higher standards as to what defines mangement than you do. That doesn't make me a troll.
More significantly, it has shown up as an application workspace paradigm that improved previously crappy MDI implementations in programs like Visual Studio and KDevelop.
It's "everyone else's" apparently but you can't point at anyone who actually defines it that way.
Oh God, I've gone past being provoked by your crap and now I'm laughing. Yes I have pointed out at least 4 seperate groups who define it this way and could point out many more. You're still not reading what you're responding to, probably because you're too busy taking a minor comment against your distribution and some kind of personal attack.
* Slackware hasn't got dependency checking. RedHat, Debian, BSD does. Slackware is out. And Solaris, HPUX, etc.
* RedHat doesn't have automatic downloading of packages. BSD and Debian do.
Red Hat does and has had for a long time, you're not not very well informed. up2date has existed for two years now and is quite mature.
RedHat is therefore not a packaging system because "all the other" packaging systems do.
Solaris and HPUX don't have auto download system that come with their, though I know a third party one is avaliable for Solaris. But then again, the tasks of an auto downloader can also be handled via an indexing engine or `ls' on a CDROM
* BSD allows (etc)
That's one. One does not make a majority, especially when others have alternate machanism of doing the same thing.
Your little recap is pathetic. I have justified it repeatedly. You said I haven't pointed out anyone who defines packaging this way. That's provably false and indicative that you're not reading what you're responding to. So whose not listening to who?
Your a fool who responds to any sort of tuned criticism to a piece of technology they used as if it was a personal attack. Grow up, mister Coward.
With respect, that's the first time you've actually tried to justify your definition with something remotely concrete
Reread what I've posted earlier. I made this point multiple times. In fact, read the title of the comment you responded to earlier. You're quite slow.
Slackware's package system was one of the first created.
It was one of the last, and added some metadata to the existing archive system and some very basic tools with the word `pkg' in their name, in response to people choosing other distroibutions precisely because they offered package management systems.
No, you were responding to my posting and claiming my use of the word packages was incorrect wrt Slackware packages.
I had a feeling that was the case, but I frankly could not be bothered re-reading my earlier posts.
At the end of the day, you continue to be demanding a feature be part of the definition of package management systems which is not useful on its own
I have repeatedly pointed out how it is useful on its own. Package A requires package B. User installs package A, but it won't let his, because of the dependency. This is in constrast to package A being installed and the `dependency' being discoovered when something breaks. Yes this feature is useful. Yes people have can and will work with packaging systems without ever using the autodownload tools that are avaliable because `ls' on a CDROM and a web indexing engine perform these functions well.
You made up a feature that has nothing to do with package management and claimed that without it, something isn't package management!
As I said earlier: like English, computing terms are defined by their use. Everyone elses definition of packaging system with the exception of Slackware's includes a dependency system. I will bang this point into your head repeatedly and sometime you might actually respond to it.
Oh yes, installing the other packages is for something else to do!
No, finding and downloadoing. They're not the same.
But it should complain anyway, even though such complaints are useless because, er, they enforce integrity.
Those complaints are not useless, because they enforce integrity. I.e, what's installed on the system works properly. Don't manipulate my words into somethign else. Quote me.
That's funny, because from where I sit, you're (not) responding to the sentences to which they're attached.
Respond to the point I make yet again in the first paragraph I write in this post. You haven't yet.
Pretty much a standard troll from what I can see.
Someone rampa
Invent a definition
No, I've provided reasons why that defintion is the case. You still haven't responded to me.
claim it's "the definition"
Back up the defintion because its the way everyone else defines it.
then respond word by word in such a way that you don't actually have to respond to your victim's arguments.
LISTEN TO ME. Not, not your own version of the words like you've posted above, but what I'm actually saying.
/me picks up your head and slams it repeatedly in the ground while screaming EVERYBODY ELSE'S PACKAGING SYSTEM INCLUDES THESE ABILITIES WHICH ARE USEFUL ON THEIR OWN BECAUSE THEY MAKE SURE WHATS INSTALLED ON THE SYSTEM ACTUALLY WORKS. COMPUTING TERMS ARE DEFINED BY THEIR USE, AND EVERYBODY ELSES CONCEPT OF A PACKAGING SYSTEM IS PARTICULARLY DIFFERENT FROM SLACKWARES
Don't even dare say I haven't responded. Listen to someone asides from yourself for a change.
That's it. I can say that something is "part of the common definition" too but I'd be speaking out of my arse unless I actually backed it up.
I have backed it up. Like the English language, computing terms are (like it or not) defined by their use. Everyone elses definition of a packaging system includes these abilities. Slackware's is unique in that it does. Read that again, and this tiem respond to it.
You're proposing that something utterly and completely useless on its own is vital part of package management.
Why is it completely and utterly useless on its own? It still enforces correct system administration proceedures and coherantly installed software. Back up your argument.
That's resorting to some kind of sneering elitism!
That `sneeering elitism' is whats known as management - enforcing and maintaining particular characteristics of that which is being managed.
Archives do not have post-install/uninstall scripts.
Yeah, archives aren't packages. Archives were brought up in response to another fellow that said that the definition of a `package' from an English disctionary was appropriate. It obviously isn't.
Haing a look at his picture there I saw a familiar face. I spoke to marcelo at Linux.conf.au - if he's the person I thought of, we had a gand old chat about Connectiva's porting of the APT software installation system to the RPM package manager. He's a good guy and quite approachable - I'm a system administrator, and although I have some coding skills (I know some ionterpreted languages and can read C, but that's about it right now) my experience with Linux is mainly as a user and maintainer rather than a developer. Marcelo (like AC, who I also met that trip) was a pleasant and approachable fellow, and it surprised me how both men were happy to converse with anyone without that occasional sense of elitism and self importance that one can get from...well, packet filtering maintainers:).
From what it seems, the Wine -> NSPlugin32 bridge and the menu is proprietary.
All the other code is contributed into Wine, which was BSD licensed (I think last time I looked. Codeweavers of course pays the salary of Wine founder Alexandre Julliard and many other major wine developers, including their work on enhacing the Open Source one.
I'm happy with that and I think most people should be.
If you're going to say "such and such isn't a packaging system unless it has x-irrelevent-but-useful-to-me-feature"
I'm not going to say that at all,that's why I haven't. I've said the common definition of a packaging system. And that's exactly what I meant, oddly enough.
then you should at least justify its usefulness.
I have. You should at least read the post you're replying to. See comments about enforcing cohensive software installations.
Arguing that a package management system must have the capability to check dependencies, even if it doesn't in any way make use of that information, is adding a pointless barrier to entry.
No its not. Its enforcing integrity on the system. How easy it is for people to meet that integrity has generally been treated as a seperate issue.
Codeweavers Crossover allows you to view Apple Quicktime. Shockwave, Ipix, and other Win32 based browser plugins under Linux.
it uses Wine, buts in a much more limited and controllable environment, meaning its a lot more stable. It supports any browser which support the Netscape plugin API (Galeon, Mozilla, etc) but bugs in Konq nspluginapi implementation means that Konq and Quicktime is a no goer (currently anyway).
Its twenty US bucks and the cash goes towards the salaries of the fellows who work on the free, main Wine project. it can be clunky at times 9when running Quicktime as a standalone app) but generally its OK. Galeon, OTOH, works with it a treat. I've viewed every single trailer at apple.com with it (to the point of being kicked off my ISP for bandwidth overuse:D ).
Version 1.01 is coming out this week, BTW, which apprently fixes a lot of the bugs of earlier versions.
its a good product and worth the small price. The money also goes to a good cause that contributes to the community.
Dependency checking is pretty much pointless unless it includes dependency fetching which is much more difficult.
That's a seperate issue - see below.
Using both Slackware's packaging system (which you don't think is a packaging system, because while it manages packages
Archives. And the level of management is doubtful
and RedHat's (which does), an installation will fail if you haven't installed a dependency.
By the common definition downloading dependencies is not part of a packaging system. By common definition discovring and recording those dependencies is. Neither Red Hat or Debian or Solaris packaging systems (nor any other I know of) include the ability to automatically download packages. Instead, higher levels tools like up2date, APT, or pkg-get perform these functions. However, the packages in each contain dependency information, and dependencies must be met before software in installed, enforcing a well maintained and cohesive system.
Under definition 2, PKZip is a packaging system.
If you ask anyone whose remotely familiar with packaging systems, they'd naturally tell you it wasn't.
Lets follow this logic, and look up a non computer dictionary for more computing terms.
Oer, apparently my/etc/shadow is filled with some sort of intoxicating resin, chopped meat, or something chopped into pieces.
Is it possible, just possible that non computer dictionaries don't know anything whatsoever about specific technical terms with well accepted meaning?
Keep your own special definition of packaging system. I'm just letting you know that everyone else who makes packaging systems doesn't agree that appending `pkg' to an application makes it a packaging system.
Terribly sorry to ruin your soapbox. Do go on though, it was *almost* interesting.
Oer, feel the provocation!/me wets himself.
Terribly sorry to ruin your soapbox. Do go on though, it was *almost* interesting.
No, Sun just doesent include every package and application under the sun
Last time I checked they did, shipping with and turning on unnecessary RPC based services, Telnet servers, and having a fucking Netscape based install process (that was avoidable, at the expense of missing out of some features. There's at the useless dt* programs I'm not aware that anyone uses.
with a nice point-and-drool web-based sysadmin interface.
If I remember correctly both Admintool and Solaris Management Console (or whatever its called - that thing that used to be in Easy Access Server) are both installed by default in Solaris 8.
In addition, it seems they don't give anything a modern Unix server needs out of the box - like Tripwire (or another IDS) and some basic default packet filtering system (although Sun does give away their basic firewall product for free).
If you're talking about default installs, give me Red Hat 7.2 anyday.
By almost veryone's definition these are methods of installing software but not packaging systems, Packaging systems (that is EVERY one I know of with the exception of Slackaware's) are designed to manage software in small chunks with some kind of metadata describing how packages relate to eachother - i.e. dependencies.
I've been sold the slackware `packagaing system' doesn't have dependencies. If that's true, it isn't a packaging system. Nothing wrong with that, but less call a software install method a software install method.
In my eyes, indisposed, in disguises no one knows...
Re:Another reason stopping people from using Netsc
on
Netscape 6.2
·
· Score: 2
IE doesn't really dither it's interface -- it uses different icons for low-color installs.
The first part's false, the second part's true. It does dither its interface - the HTML rendering part. View Slashdot, Netscape.com, etc side by side in IE and NS 6 on a 256 color Windows box to see what I mean.
Another reason stopping people from using Netscape
on
Netscape 6.2
·
· Score: 2
Large corporates are conservative and slow in moving from one platform to another. They'll be running Netware and Notes for a very long time (and good on them) and they might have even stuck with their old standard Netscape browser apart from one minor detail:
Netscape isn't useable in most Terminal Services environments - essentially because large TS environments often use low (256) color displays and its dithering is piss poor. On a Windows box, view netscape.com in IE and Netscape. Its nearly unreadable in Netscape, as is most of the NS UI (even in classic mode). IE, on the other hand dithers extremely well, to the point where its possible to believe you were looking at a high color display.
There's enough people tired of running Windows based desktop but keen on the Win32 platform to make TS compatibility a big concern when selecting an SOE. Goodbye Netscape.
/me types this in IE on his Linux box using Rdesktop. Well recommended for non MS TS clients.
The transgaming patches are NOT closed source, they are just not Free Software. You can download them (see the winex project on sourceforge) or get them from CVS, you just can't use them for anything commercial.
if you define that which is not Open Source is closed source (as most Linux users do).
The Open Source Definition defines (oddly enough) what Open Source means. The non commercial restriction violates these guidelines and means that Transgamings patches are not open source.
WineX is `source code available' software (although thats not a well definied term), like Qmail, TinyDNS, Microsoft PocketPC, or Pine.
Slashdot Mirror
The user is still going to have to look for the files that resolve those dependencies. So I run galeon after installing it with Slackware and find it needed Mozilla - do you think I'd have been better off if the package manager, rather than the app - whose dependency can be resolved in a myriad of different ways - had refused to install it demanding a particular package be installed?
Yes!
manages packages can be described as being anything other than a package manager.
By not managing them to an acceptible standard.
(insert obligatory response to rather uncreative troll label here)
Mike
do this task for around for years
Er, `do this task for around four years'
or
`do this task for years'
The above makes no sense.
The wheel hasn't changed significantly over the years in terms of the base concepts behind it. Is this a good thing or a bad thing.
.A GNOME app under KDE still feels like...a GNOME app under KDE. Red Carpet is a brilliant ap but it acts differently from all the other KDE apps on my desktop. That really sucks. Standardization will hurt lots. The LSB settled on the RPM packaging system, told distros not to put things in /opt, and said init scripts must live in /etc/init.d. Some distros who had minor things to change have modified the way they are, but expect screaming when someone dare suggests the non-RPM distros convert.
Its postive:
* Unix is easily the most reliable popular desktop, or server Operating System. Uptimes can and have been measured in years
* Modern Unix (of which Linux is the standard, but keep that low for now) is open, uses documented APIs, and provides users with great choice and flexibility as to how their machines work
* I've got high standard, and the ability to reconfigure a machine for say to day maintenace tasks without rebooting is in my opinion a standard part of any real server OS.
* Despite what most Slashdotters think, a modern Unix machine is capable of being used and administered entirely through its GUI or via the scripting-happy command line.
* Root sucks or rather, relying on one particular account to be the sole administrator sucks, and this si what most Unixes do. That stems from another problem
* RWX permissions suck. There's good replacements that work well and are just as easy to administer, but Linux, most BSDs, and many proprietary Unixes still use dodgy permissions which weren't desgned for security. Not being able to have any kind of fine grained control over who has access to a file sucks.
* lack of standardization hurts the platform. GNOME versus KDE hurts by dividing effort more than it helps by providing competition
A while back I was going through three-year-old modem logs looking for records of someone dialing in (billing dispute): grep for the UID, piped to awk to add up the time online, convert it to hours and print it out, piped to sendmail to mail it to the billing dept...
You can't do that with in WIMP environments, God bless 'em
Why not? Most GUI environments have had scripting capabilities to do this for a while, Windows has been able to do this task for around for years, and I'm sure Apple scripting language (not sure of its name - Applescript sounds obvious) can do it too.
What's Unix specific about it? Scripting rocks, but its hardly unique.
Nice to know ytou thought up such an adequate and complete retort :D
Where? I've yet to see you show ANYONE as agreeing with your definition.
/opt, can't install RPM packages, or put things in unusual places can be defined as not being Linux in that they do not meet the Linux Standard Base. They're just OS which use the Linux kernel. Controversial now, but it will be pretty common in five years time.
...well... manage packages. I have higher standards as to what defines mangement than you do. That doesn't make me a troll.
I've explained why this is the case earlier. Use defines definition. This seems to elude you.
So presumably this now means your barrier to entry has changed and all packaging systems must not only check dependencies - but resolve them too?
No. And I don't follow your logic.
In any case, you've totally avoided answering the point. I've whittled down the list of "package managers" each time by finding a feature that is in all those left save one.
Really? Omigod! And you've missed the point: I've refuted your argument save for slackware. More importantly: the only `feature' which is based on making a system stabler, rather than saving time for administrators, is dependency checking.
To put it another way, every single Linux distribution out there has a package management system to ensure that it's easy to install, track, uninstall, and upgrade, components of the system in a modular way.
Again, making sure what's installed on the system WORKS is a big part of that.
If you're arguing that Slackware lacks such a system, and you agree that every other Linux distribution has a package management system as part of it, do you thus believe that Slackware is not a Linux distribution?
That's not that difficult to say. Distributions which install software in
Or did you mean "You're"
Oh God. Too much time online and too much anger in my mind when I wrote that.
Spelling flames are usually lame
Yeah they are, but mea culpa.
So you agree then that it is a packaging management system and your claims that it isn't are merely insults for the sake of criticism rather than intended to be taken seriously?
No I don't. Quoting me saying Slackware is a `piece of technology' and using this as evidence I believe Slackware is a packaging system is just as bad an abuse of logic as my own abuse of English (you're / your) above.
You're defining package management as meaning more than the management of packages.
No, I've said keeping a system stable is part of management. Ignoring that and not responding to it is `just dumb'.
As for the personal attacks, I started out as merely disagreeing with you, as the other posters did. You chose to turn that into a stream of insults.
I never insulted anyone until being told by someone"Terribly sorry to ruin your soapbox. Do go on though, it was *almost* interesting." . You chimed in with your own chilidsh little imitative misquote. And you dare call *me a troll?
What exactly is it about Slackware package management that riles you this way?
Nothing. I'm just cautious about anything which harms the integrity of a system. Finding out the installed software requires another piece of software post install is simply poor engineering and bad for the integrity of the installed system. As I've said before: there's nothing majorly wrong with Slackware's software installation system if that's all you want or need, its just not a packaging system.
I mean, for crying out loud, you've started an entire subthread here about how upset you are
I'm not upset, or at least I wasn't until your annoying little `let me see...you think all Slackware users are Pterodactyls!!!'-type manipulations of my words.
I've riled the feathers of people who like a piece of technology too much to acknowledge it has obvious faults. I don't expect you to agree with me, but I do expect some respect and for you to actually read my postings (which you have not) before you (Mister AC) choose to label *me* as a troll.
We both agree that a package management should
More significantly, it has shown up as an application workspace paradigm that improved previously crappy MDI implementations in programs like Visual Studio and KDevelop.
KDE, like Windows and MacOS, has user interface guidelines which strongly discourage MDI apps.
I'd post a snippet, but the Slashdot lameness filter is being...well, lame. Go to the URL above.
It's "everyone else's" apparently but you can't point at anyone who actually defines it that way.
Oh God, I've gone past being provoked by your crap and now I'm laughing. Yes I have pointed out at least 4 seperate groups who define it this way and could point out many more. You're still not reading what you're responding to, probably because you're too busy taking a minor comment against your distribution and some kind of personal attack.
* Slackware hasn't got dependency checking. RedHat, Debian, BSD does. Slackware is out.
And Solaris, HPUX, etc.
* RedHat doesn't have automatic downloading of packages. BSD and Debian do.
Red Hat does and has had for a long time, you're not not very well informed. up2date has existed for two years now and is quite mature.
RedHat is therefore not a packaging system because "all the other" packaging systems do.
Solaris and HPUX don't have auto download system that come with their, though I know a third party one is avaliable for Solaris. But then again, the tasks of an auto downloader can also be handled via an indexing engine or `ls' on a CDROM
* BSD allows (etc)
That's one. One does not make a majority, especially when others have alternate machanism of doing the same thing.
Your little recap is pathetic. I have justified it repeatedly. You said I haven't pointed out anyone who defines packaging this way. That's provably false and indicative that you're not reading what you're responding to. So whose not listening to who?
Your a fool who responds to any sort of tuned criticism to a piece of technology they used as if it was a personal attack. Grow up, mister Coward.
With respect, that's the first time you've actually tried to justify your definition with something remotely concrete
Reread what I've posted earlier. I made this point multiple times. In fact, read the title of the comment you responded to earlier. You're quite slow.
Slackware's package system was one of the first created.
It was one of the last, and added some metadata to the existing archive system and some very basic tools with the word `pkg' in their name, in response to people choosing other distroibutions precisely because they offered package management systems.
No, you were responding to my posting and claiming my use of the word packages was incorrect wrt Slackware packages.
I had a feeling that was the case, but I frankly could not be bothered re-reading my earlier posts.
At the end of the day, you continue to be demanding a feature be part of the definition of package management systems which is not useful on its own
I have repeatedly pointed out how it is useful on its own. Package A requires package B. User installs package A, but it won't let his, because of the dependency. This is in constrast to package A being installed and the `dependency' being discoovered when something breaks. Yes this feature is useful. Yes people have can and will work with packaging systems without ever using the autodownload tools that are avaliable because `ls' on a CDROM and a web indexing engine perform these functions well.
It's not a convincing argument
You're not listening to it.
You made up a feature that has nothing to do with package management and claimed that without it, something isn't package management!
As I said earlier: like English, computing terms are defined by their use. Everyone elses definition of packaging system with the exception of Slackware's includes a dependency system. I will bang this point into your head repeatedly and sometime you might actually respond to it.
Oh yes, installing the other packages is for something else to do!
No, finding and downloadoing. They're not the same.
But it should complain anyway, even though such complaints are useless because, er, they enforce integrity.
Those complaints are not useless, because they enforce integrity. I.e, what's installed on the system works properly. Don't manipulate my words into somethign else. Quote me.
That's funny, because from where I sit, you're (not) responding to the sentences to which they're attached.
Respond to the point I make yet again in the first paragraph I write in this post. You haven't yet.
Pretty much a standard troll from what I can see.
Someone rampa
Invent a definition
No, I've provided reasons why that defintion is the case. You still haven't responded to me.
claim it's "the definition"
Back up the defintion because its the way everyone else defines it.
then respond word by word in such a way that you don't actually have to respond to your victim's arguments.
LISTEN TO ME. Not, not your own version of the words like you've posted above, but what I'm actually saying.
/me picks up your head and slams it repeatedly in the ground while screaming EVERYBODY ELSE'S PACKAGING SYSTEM INCLUDES THESE ABILITIES WHICH ARE USEFUL ON THEIR OWN BECAUSE THEY MAKE SURE WHATS INSTALLED ON THE SYSTEM ACTUALLY WORKS. COMPUTING TERMS ARE DEFINED BY THEIR USE, AND EVERYBODY ELSES CONCEPT OF A PACKAGING SYSTEM IS PARTICULARLY DIFFERENT FROM SLACKWARES
Don't even dare say I haven't responded. Listen to someone asides from yourself for a change.
That's it. I can say that something is "part of the common definition" too but I'd be speaking out of my arse unless I actually backed it up.
I have backed it up. Like the English language, computing terms are (like it or not) defined by their use. Everyone elses definition of a packaging system includes these abilities. Slackware's is unique in that it does. Read that again, and this tiem respond to it.
You're proposing that something utterly and completely useless on its own is vital part of package management.
Why is it completely and utterly useless on its own? It still enforces correct system administration proceedures and coherantly installed software. Back up your argument.
That's resorting to some kind of sneering elitism!
That `sneeering elitism' is whats known as management - enforcing and maintaining particular characteristics of that which is being managed.
Archives do not have post-install/uninstall scripts.
Yeah, archives aren't packages. Archives were brought up in response to another fellow that said that the definition of a `package' from an English disctionary was appropriate. It obviously isn't.
Haing a look at his picture there I saw a familiar face. I spoke to marcelo at Linux.conf.au - if he's the person I thought of, we had a gand old chat about Connectiva's porting of the APT software installation system to the RPM package manager. He's a good guy and quite approachable - I'm a system administrator, and although I have some coding skills (I know some ionterpreted languages and can read C, but that's about it right now) my experience with Linux is mainly as a user and maintainer rather than a developer. Marcelo (like AC, who I also met that trip) was a pleasant and approachable fellow, and it surprised me how both men were happy to converse with anyone without that occasional sense of elitism and self importance that one can get from...well, packet filtering maintainers :).
From what it seems, the Wine -> NSPlugin32 bridge and the menu is proprietary.
All the other code is contributed into Wine, which was BSD licensed (I think last time I looked. Codeweavers of course pays the salary of Wine founder Alexandre Julliard and many other major wine developers, including their work on enhacing the Open Source one.
I'm happy with that and I think most people should be.
Nope.
,that's why I haven't. I've said the common definition of a packaging system. And that's exactly what I meant, oddly enough.
How very Slashdot of you.
If you're going to say "such and such isn't a packaging system unless it has x-irrelevent-but-useful-to-me-feature"
I'm not going to say that at all
then you should at least justify its usefulness.
I have. You should at least read the post you're replying to. See comments about enforcing cohensive software installations.
Arguing that a package management system must have the capability to check dependencies, even if it doesn't in any way make use of that information, is adding a pointless barrier to entry.
No its not. Its enforcing integrity on the system. How easy it is for people to meet that integrity has generally been treated as a seperate issue.
I assume...
You assume wrong.
Codeweavers Crossover allows you to view Apple Quicktime. Shockwave, Ipix, and other Win32 based browser plugins under Linux.
:D ).
:D
it uses Wine, buts in a much more limited and controllable environment, meaning its a lot more stable. It supports any browser which support the Netscape plugin API (Galeon, Mozilla, etc) but bugs in Konq nspluginapi implementation means that Konq and Quicktime is a no goer (currently anyway).
Its twenty US bucks and the cash goes towards the salaries of the fellows who work on the free, main Wine project. it can be clunky at times 9when running Quicktime as a standalone app) but generally its OK. Galeon, OTOH, works with it a treat. I've viewed every single trailer at apple.com with it (to the point of being kicked off my ISP for bandwidth overuse
Version 1.01 is coming out this week, BTW, which apprently fixes a lot of the bugs of earlier versions.
its a good product and worth the small price. The money also goes to a good cause that contributes to the community.
No, I don't work for them
Dependency checking is pretty much pointless unless it includes dependency fetching which is much more difficult.
That's a seperate issue - see below.
Using both Slackware's packaging system (which you don't think is a packaging system, because while it manages packages
Archives. And the level of management is doubtful
and RedHat's (which does), an installation will fail if you haven't installed a dependency.
By the common definition downloading dependencies is not part of a packaging system. By common definition discovring and recording those dependencies is. Neither Red Hat or Debian or Solaris packaging systems (nor any other I know of) include the ability to automatically download packages. Instead, higher levels tools like up2date, APT, or pkg-get perform these functions. However, the packages in each contain dependency information, and dependencies must be met before software in installed, enforcing a well maintained and cohesive system.
Under definition 2, PKZip is a packaging system.
/etc/shadow is filled with some sort of intoxicating resin, chopped meat, or something chopped into pieces.
/me wets himself.
If you ask anyone whose remotely familiar with packaging systems, they'd naturally tell you it wasn't.
Lets follow this logic, and look up a non computer dictionary for more computing terms.
Oer, apparently my
Is it possible, just possible that non computer dictionaries don't know anything whatsoever about specific technical terms with well accepted meaning?
Keep your own special definition of packaging system. I'm just letting you know that everyone else who makes packaging systems doesn't agree that appending `pkg' to an application makes it a packaging system.
Terribly sorry to ruin your soapbox. Do go on though, it was *almost* interesting.
Oer, feel the provocation!
Terribly sorry to ruin your soapbox. Do go on though, it was *almost* interesting.
No, Sun just doesent include every package and application under the sun
Last time I checked they did, shipping with and turning on unnecessary RPC based services, Telnet servers, and having a fucking Netscape based install process (that was avoidable, at the expense of missing out of some features. There's at the useless dt* programs I'm not aware that anyone uses.
with a nice point-and-drool web-based sysadmin interface.
If I remember correctly both Admintool and Solaris Management Console (or whatever its called - that thing that used to be in Easy Access Server) are both installed by default in Solaris 8.
In addition, it seems they don't give anything a modern Unix server needs out of the box - like Tripwire (or another IDS) and some basic default packet filtering system (although Sun does give away their basic firewall product for free).
If you're talking about default installs, give me Red Hat 7.2 anyday.
By almost veryone's definition these are methods of installing software but not packaging systems, Packaging systems (that is EVERY one I know of with the exception of Slackaware's) are designed to manage software in small chunks with some kind of metadata describing how packages relate to eachother - i.e. dependencies.
I've been sold the slackware `packagaing system' doesn't have dependencies. If that's true, it isn't a packaging system. Nothing wrong with that, but less call a software install method a software install method.
Or is it just me who read that Black Hole Sun .
In my eyes, indisposed, in disguises no one knows...
IE doesn't really dither it's interface -- it uses different icons for low-color installs.
The first part's false, the second part's true. It does dither its interface - the HTML rendering part. View Slashdot, Netscape.com, etc side by side in IE and NS 6 on a 256 color Windows box to see what I mean.
Large corporates are conservative and slow in moving from one platform to another. They'll be running Netware and Notes for a very long time (and good on them) and they might have even stuck with their old standard Netscape browser apart from one minor detail:
Netscape isn't useable in most Terminal Services environments - essentially because large TS environments often use low (256) color displays and its dithering is piss poor. On a Windows box, view netscape.com in IE and Netscape. Its nearly unreadable in Netscape, as is most of the NS UI (even in classic mode). IE, on the other hand dithers extremely well, to the point where its possible to believe you were looking at a high color display.
There's enough people tired of running Windows based desktop but keen on the Win32 platform to make TS compatibility a big concern when selecting an SOE. Goodbye Netscape.
/me types this in IE on his Linux box using Rdesktop. Well recommended for non MS TS clients.
btw, in regards to your sig, What about a Ranting Unix user who has a MCSE??????
;)
We're few and far between
Come on, who didn't burst out laughing when they saw Future Tech's website?
The transgaming patches are NOT closed source, they are just not Free Software. You can download them (see the winex project on sourceforge) or get them from CVS, you just can't use them for anything commercial.
if you define that which is not Open Source is closed source (as most Linux users do).
The Open Source Definition defines (oddly enough) what Open Source means. The non commercial restriction violates these guidelines and means that Transgamings patches are not open source.
WineX is `source code available' software (although thats not a well definied term), like Qmail, TinyDNS, Microsoft PocketPC, or Pine.