Re:Please seperate Linux kernel from Linux OS topi
on
Linux 2.4.18 Released
·
· Score: 2
Difference being that there's enough of the former people to care about it, which is why it keeps coming up. Ranting about how other people dare ask for a choice sucks.
Re:Please seperate Linux kernel from Linux OS topi
on
Linux 2.4.18 Released
·
· Score: 2
Take the Linux kernel updates out of the Linux OS topic? If you do that, then you'd have to rename the Linux OS topic to "GNU-based OS" topic because the only thing that makes Linux Linux is the kernel.
Yeah, the kernel. And all the drivers within that kernel that only Linxu supports, like filesytems and packet filters. And the FHS, and the LSB and the standards they entail, like SysV and RPM. And all those the distributions that don't distribute other OSs (everyone except Debian). And all the software ports that are for Linux and not for any other Unix. And the various political issues which surround Linux and not BSD and other OSes.
Yeah, there's no Linux OS or Linxu specific issues. If that were the case, you'd have crazy stuff for each individual Unix OS, like a BSD section or apple.slashdot.org, and we all know that would never happen, right?
Its about signal noise ratio. You don't seem to understand that.
Re:Please seperate whiny Linux kernel comments...
on
Linux 2.4.18 Released
·
· Score: 2
Please seperate whiny Linux kernel comments... (Score:1) by festers
Yeah, people who whine suck;)
Re:Please seperate Linux kernel from Linux OS topi
on
Linux 2.4.18 Released
·
· Score: 2
This is off topic, but actually, I think I'd be using the BSD tools (with the Linux kernel). Yes the FSF deserves credit for their work, but so do many other projects, like KDE, GNOME, BSD, etc.
Please seperate Linux kernel from Linux OS topic
on
Linux 2.4.18 Released
·
· Score: 2, Interesting
You've all heard this before, but that way people who aren't particularly interested in minor kernel revisions but are interested in general Linux stories can filter away the linux kernel topic.
I always thought this was Sun's Staroffice strategy - deprive MS of income from MS Office, which provides around 40% of their revenue, by providing a quality (quality is a new feature they added in StarOffice 6 beta and up) office suite for $free on Windows, Linux, and Solaris.
This also makes Staroffice a gateway to other platforms - customers using StarOffice 6 on Windows can install Linux desktops or Suntone's and not be without their critical productivity apps.
Closed source software is software distributed purely as binary
Logically, its software which isn't Open Source. Obviously Mplayer's license is much more restrictive than Open Source or Free Softwarre (which it isn't either).
Further, the Open Source Initiative is not the be all and end all of open source.
Yes they are. They invented the term, they get to decide what it means. If it wasn't for the Open Source Initiative you wouldn't be talking about Open Source or using it to describe software.
They can't stop other people from describing their own software, distributed as source code, as open source
They can and have pressured people who have abused this term to mean something other than what it does before, and the offencind parties have generally changed their license or stopped usign the term incorrectly. The only reason Open Source isn't a trademark is that this would require the OSI to police unauthorized use and approve the use of the term every time it is used to maintain the tradmark, which would be a waste of resources. This doesn't give you a license to make a closed source license like mplayer as Open Source because you get the code. By this logic, Pine, Qmail, and Windows 2000 are all Open Source because you can get code. In all cases (just like mplayer's) you can't do much with it. Its just that the authors of these tools don't tell people their apps are Open Source when they are clearly not.
though perhaps they have some claim to Open Source(tm)
As said earlier, there is no Open Source trademark. If you're knowledgable re licensing it surprises me you don't know that.
- although clearly some idiots would like them to have that power.
Yes, just because a bunch of people created a term, a definition of the term, an organization to support and promote the use of that term, certification tests for that term, and allow people who make software available under that definition to use that term doesn't mean they know anything about that term, certainly less than some troll on IRC who's likely an mplayer developer.
Photoshop for OS X [OS X (Apple)] Posted by michael on Sun February 24, 06:21 AM from the brighter-colors-and-whiter-whites dept. MolGOLD writes: "Well, finally OS X users are getting their wish: Adobe has finally made good on their promise to bring native OS X support to their graphical applications. C|Net is running a story on the upcoming version of Photoshop, which will feature native OS X support. Now that Photoshop 7 will run natively under OS X, will we see companies like Macromedia (who also promised native OS X support) hurry along to follow suit?"
The 'Open Source Definition' isn't the be all and end all of what is and isn't open source
Yes, it is. It is the definition, oddly enough, of Open Source. By the people who invented the term, the Open Source Initiative. The MPlayer list license not on the OSI list of approved Open Source licenses, and many licenses with similar restrictions have been refused approval for the list. MPlayer is not Open Source as it doesn't meet criteria 2 of the definition. If it applied for OSI Certification, it would be rejected.
but with the increasing dependance on file formats that have no support on Linux, it's going to be awfully difficult.
I don't think the person who wrote this has much of an idea about using Linux on the desktop either. Which file formats is he talking about?
Doc, XLS, ppt, etc are suppoting by Staroffice and OpenOffice, as well as many other Linux apps (though most don't do as good a job as StarOffice 6.
Windows Media 7 and 8 video is supported by both the Open Source Xine and the closed source Mplayer apps. mms:// streams (streaming WMV) are supported by a recently released Xine plugin
Flash is both an open standard and has many Linux implementations, Open and closed. The best still seems to be Macromedia's though, but it works well natively.
Likewise PDF.
RealOne (the successor to RealPlayer is native to Linux
Quicktime, Shockwave, QuicktimeVR, Ipix, and other file formats are supported through Codeweavers Crossover, which geneally works quite well.
Zip. Supporting by zlib.
MP3, supported by everything
Ogg. Hell yeah.
DivX - Xine or Mplayer for playing, Drip or Transcode for creating.
HTML. Obvious.
MSHTML - KDE's Konqueror uses an IE like feature where non DTD documents (ie, broken HTML) are rendered uses a different set of rendering rules, meaning most MSHTML displays well.
The situation looks pretty good in my opinion for Linux to play 98% of what every desktop user wants to play.
Problem file formats
Windows media 7 and 8 audio. AFAIK there is no player for this file fomrat under Linux. Its not anywhere near as popular as WMV, but a player would still be nice.
Me>> Scanning for and removing mail viruses should be handled by your mail gateway (as well as your desktops for the following reasons).
But what about other ways for virii to enter the network? Not everything comes in via POP/SMTP.
Yes. That's why I just said that:).
APT-get the Red Hat packages
on
GNOME 2.0 Beta
·
· Score: 5, Informative
For Red Hat users, packages of Gnome 2.0 for Red Hat 7.2 should be available within Gnomehide reasonably soon, depending on how fast Havoc Pennington updates GNOMEhide (usually within a week, judging by previous announcements).
Add the following lines to your sources.list
# Red Hat Linux Rawhide #rpm http://apt.nixia.no redhat/rawhide/i386 cds #rpm http://apt.nixia.no redhat/7.2/i386 gnomehide
PS - If any of you have the bandwidth to host a publically avaliable apt repository for Red Hat, then please post to the freshrpms mailing list and tell us all about it.
Scanning for and removing mail viruses should be handled by your mail gateway (as well as your desktops for the following reasons). 1) This way viruses are removed from your network at first opportunity 2) You can bounce messages and let the sender / recipient / admin know the sender has a potential virus problem 3) One server is easier to maintain than a few hundred desktops 3) 2 layers provide more protection than one 4) Why waste resources getting virus laden enail to desktops? A mail gateway provides a convenient choke point to get this stuff out of your network ASAP.
With that in mind here's a guide I wrote for my employer for doing so at clients, using Red Hat Linux, Postfix, and Sophos MailMonitor.
In the setup outlined below, 1) Postfix accepts incoming mails on port 25 and leads them to a content_filter. 2) The content_filter is Sophos MailMonitor, which takes over the mails on port 10025. After the mails have been scanned, they are placed back to postfix on port 10026. 3) Finally postfix delivers the mails.
The dependency and dependency resolution system- dpkg has the most advanced dependency system known to unix. No dobut to that... To solve these dependencies, dpkg goes to it's list of package locations (complete with http and ftp locations, cdroms, etc.. if necessary) and grabs the required packages from the net (the user is prompted on this, of course)
Dpkg doesn't do that. APT does. Its not that these aren't great and massively useful features, its just that just like urpmi, APT works its magic across RPM (the LSB standard packaging system, which many app packagers primarily package for) too. I maintain an apt repository for my workplace with around 3000 packages, all in RPM format for Red Hat 7.2, and it works like a charm. Debian's policies are postable too - Connectiva has a similar set of guidelines. The unique advantages of Dpkg is suggested / recommended dependencies, something RPM desperately needs (Red Hat themselves cheat and use the `comps' file to provide this logic themselves in the installer, but us users don't have the luxury). RPM has some unique advantages too tho - transaction handling in the database (thanks to DB3) does wonders for my piece of mind. In the end, I'll stick with RPM and Apt-get because of the LSB stuff, and avaliability, but I do hope they add suggested / recommended dependencies soon.
Actually, if you want to see a system which kicks both their arse in many ways, look at QNX. They have apt-like features, a nifty `package filesystem', and a GUI installer that reallycraps all over every other software install system I've ever seen.
Menus. Red Hat's/etc/applnk and Debian's menu system already solve this problem to a limited extent, but not everyone (or anything close to it) uses these mechanisms. One directory, in/etc (read the FHS as to why) should be used by both. Flags to hide certain things (gnome control center) in certain environments should be a part of this.
Display manager session types. As someone who manages a large amoutn of packages for my office, it annoys me that I have to repackage enlightenment, twm, pwm, qvwm95 and everything else to add the correct entry for the sessions in two locations, one for KDM and one for GDM (our office uses GDM, but I like doing things properly).
Mime types. File type editors in both desktops are already tragic enough without adding the hassle of having to add apps twice. Again, packagers must account for both sets of configs
Applets. Less of a concern, but its hard explaianing to users that you can runevery GNOME app you want in KDE, except for the applets, which won't work in the KDE taskbar (and vice versa).
Why not use the standard tools we're already using today... autoconf, m4, automake, libtool.. and have them build a "standard" config file for us at configure/build time?
Probably because a lot of the configuration files which are editied by m4 aren't considered human readable.
The problem isn't with the lack of a standardized configuration tools, its a lack of standardized configuration file formats. This allows:
Systems administrators to work with new applications config files without worrying about how exactly a comment should look
Automated parsers that don't have to be re-written for every config file - you'd have a whole buynch more webmin modules if this was the case.
GUI folk to be able to use their graphical interfaces knowing that they won't screw up a config file, because there's a very rigidly defined format for the config file and a standard parser that's very well tested
Better manipulation, imports, exports, etc of information into config files, as a popular format allows for the development of tools to perform these tasks across many different applications
This is informative? Its demonstrably incorrect for one thing, about both the FHS and how packages are handled by Alien. Problem: the people who read (and moderate) Debian stories are the ones interested in Debian to the point of excluding anything that seems counter to the direction of their distribution.
Oh well, I guess I was never going to get much of a chance.
Please don't confuse what you want the LSB to be with what the LSB is. Debian is a full member of the LSB, the packaging decision was made with Debian's approval, and it has always been understood that Alien is an acceptable solution.
I see this as a conflict within the LSB. Obviously a system which turns packagines into dumb archives is not a packaging system. Even if you said alien supports RPM installs, (I think the `P' and `M' is prettty debatable) it certainly doesn't do them well. Every Debian user I know of including myself wouldn't install a large volume of packages in standard format on a Debian box.
This is a bug withihn the LSB generated to satisfy Debian users. A rather unfortuinate compromise that will olikely bite either the LSB or Debian at some point in the future.
You're wondering if a guide to using software shoudl include instructions about installing that software: yes it should. Next question.
Yeah, I like/usr/share/doc too. Its nice that everyone's actually uses the directory, rather than installing them into/var/cache/docs and saying they `support'/usr/share/doc is that's what you want to use.
Your argument regarding changing is completely illogical. What is preventing you from changing? Just change within the standard. Policy is portable, APT already exists on RPM and I'm sure suggested/recommended dependencies woildn't be hard to implement. For servers and wrokstations, Linux should be Linux. If you want to make it something else, you have the option, but by default, it should support LSB standards in their entirety and reliably.
I don't know why you think its bad for Debian to provide their packages in.deb format.
Because Debian doesn't allow one to install a standard package and have that package work with ither software. This means a whole bunch if unecessary effort. As I've said earlier, and you've said yourself, policy has nothing to do with rpm or deb. Policy would be applicable to a LSB based Debian as well. In fact, this policy should be moved into the LSB - that's the best place for it. If one distro isn't allowing a et of packages to be installed because it causes some kind of problem, it sounds like all distros could benefit from that information. This should be obvious.
Please note that Debian and therefore DEB is older than Redhat or SuSE, AFAIK.
AFAIK that's not correct, RPM is the older system, but I can't find a URL. Not that age has anything to do with this.
Hopefully, perhaps inevitably, C++ libraries will be included as part of the LSB.
Debian does great work to make sure that everything supports the Debian menu system, for example, and any problems with the software can go through one main bug tracking system.
Either of these are still entirely possible while using standard packages. One can track . Almost every other Linux distribution has its own version of the menu system, typically/etc/applnk directory.
Getting a large piece of software like KDE working right on your distribution can take quite a bit of work.
This is precisely the problem the LSB was created to solve. Linux apps should be Linux apps.
If you want to write an LSB program, then the LSB is there for you, and Debian will support that.
Not unless I make alien work as a package manager rather than an extractor of archives.
>> A standardized packaging system is useful for more than just closed source apps - its useful for every open source app maintainer
That's what "configure; make; make install" is for.
How? How will that solve the LDP from having to write twelve million different guides to ppp because some distro decided to use a nonstandard initscript dir, packaging system, or documentation directory? It won't.
You can't tell everyone to use the same language so we don't need to translate
Nobody is forcing people to do anything. Linux distro's, if they want to label themselves LSB, should do their best to support the LSB. The current abilities of alien seem to be highly lacking in this regard. If Debian don't want stable and reliable way of installing LSB packages, they should stop hoping inanely that the packaging system decision will be reversed and simply say they have no interest in the LSB, as Slackware does.
The thing is, I believe, that if the package format were the only difference, the RPM-or-DEB issue would be moot. The reason why Debian use its own packaging scheme, and IMHO what makes it far superior than RedHat and others when it comes to install or upgrade things, is the Debian Policy.
Indeed, the Debian policy is similar - is there any reason that it wouldn't be largely portable to RPM? Conectiva (which uses standard packages) already uses Debian policy as a basis for its own packaging guidelines.
It seems that you misunderstand - Alien works great, it makes RPMs, DPKGs, and TGZs interchangeable.
Your problem comes from the fact that Redhat RPMs (like Debian DPKGs and Slackware TGZs) also contain control information.
Of course they provide control information - if they didn't, they wouldn't be management systems would they? If alien still removes this information it does not do a good job of installing packages. Rather it turns those packages into dumb archives.
Since Redhat and Debian (all releases) use differnt locations for e.g. their rc.X files (initscripts)
DJB has a number of valid criticisms [cr.yp.to] (of the FHS) that are as of yet not addressed by the LSB, or more accurately, the FHS.
Good or bad, its a standard. You'll get more pain from not sticking to a standard and fragmenting Linux than you will from adopting a standard even if you don't like every part of it. Some of DJBs recommendations (eg, a registered namespace for apps) coudl easily be included in the LSB, just as suiggested / recommended dependcies could be added to RPM if so desired (says someone who happily maintains a 3GB APT repository filled wit h RPM packages for the Red Hat machines at his workplace).
in fact the Debian Project has made FHS support a specific requirement [debian.org] in their official policy manual.
Excellent. But they really should do the same with the LSB.
The part of the FHS that you seem to be missing, is that while RPM is the official packaging format of the FHS, that doesn't mean that Redhat is automatically compliant.
True, another poster made this point earlier and I agree: all Linux distribtions should completely support RPM 3.05 packages.
Offical standard RPMs are handled by Debian via Alien flawlessly
No they are not, if they remove control information as you have earlier stated. Without this data there is no `management' and it seems alien can hardly be trusted to install a large amount of interdependent software.
Debian's pretty good with FHS support, so is RH: RH has likewise moved all/usr/doc files into/usr/share/doc, and haven't used/opt in years. Suse moved their initscripts from/sbin/init.d to the proper location, but still/opt kde. I'm glad that these efforts are being made, however greater effort on fundamental issues like the packaging system needs to be performed to stop Linux fragmenting.
Theoretically, software developers should only have to release their files as.TGZ archives
If they added standardized installs, uninstalls, information about the relationships between packages, querying / verifying machinisms, etc, this would be possible. Unfortunately they don't and it isn't: hence the need for packaging.
As a Red Hat user, it it is unfortunate but understandable that you didn't know more about the FHS and APT when you administered the Debian boxen.
I am well aware of the FHS and APT. I am well aware alien doesn't handle RPM packages beyong turning them into dumb archives. I just wanted to se if there is any attempt under way to fix this.
I'm also especially aware of how APT works: I run an APT repository for the Red Hat systems at work and my own machcine, with around 3000 packages.
Even if you had the FHS compliant rp-pppoe.RPM, using the APT/.dpkg version would be preferred, as the DPKG format has superior dependancy handling.
There are no `APT' packages - you means debs. APT run on top of the packaging system. Yes, recommended / suggested dependencies are very useful, and its good that.deb provides this. So is transaction handling for the rpm database - its good that rpm provides this. They each have their advanatges. I'd like to see the good features of deb added into RPM, and the LSB updated to this new version.
I am heartened to see that you haven't been down modded, I I hope that my post has been informative.
Slashdot Mirror
Difference being that there's enough of the former people to care about it, which is why it keeps coming up. Ranting about how other people dare ask for a choice sucks.
Take the Linux kernel updates out of the Linux OS topic? If you do that, then you'd have to rename the Linux OS topic to "GNU-based OS" topic because the only thing that makes Linux Linux is the kernel.
Yeah, the kernel. And all the drivers within that kernel that only Linxu supports, like filesytems and packet filters. And the FHS, and the LSB and the standards they entail, like SysV and RPM. And all those the distributions that don't distribute other OSs (everyone except Debian). And all the software ports that are for Linux and not for any other Unix. And the various political issues which surround Linux and not BSD and other OSes.
Yeah, there's no Linux OS or Linxu specific issues. If that were the case, you'd have crazy stuff for each individual Unix OS, like a BSD section or apple.slashdot.org, and we all know that would never happen, right?
Its about signal noise ratio. You don't seem to understand that.
Please seperate whiny Linux kernel comments... (Score:1)
;)
by festers
Yeah, people who whine suck
This is off topic, but actually, I think I'd be using the BSD tools (with the Linux kernel). Yes the FSF deserves credit for their work, but so do many other projects, like KDE, GNOME, BSD, etc.
You've all heard this before, but that way people who aren't particularly interested in minor kernel revisions but are interested in general Linux stories can filter away the linux kernel topic.
I always thought this was Sun's Staroffice strategy - deprive MS of income from MS Office, which provides around 40% of their revenue, by providing a quality (quality is a new feature they added in StarOffice 6 beta and up) office suite for $free on Windows, Linux, and Solaris.
This also makes Staroffice a gateway to other platforms - customers using StarOffice 6 on Windows can install Linux desktops or Suntone's and not be without their critical productivity apps.
Closed source software is software distributed purely as binary
Logically, its software which isn't Open Source. Obviously Mplayer's license is much more restrictive than Open Source or Free Softwarre (which it isn't either).
Further, the Open Source Initiative is not the be all and end all of open source.
Yes they are. They invented the term, they get to decide what it means. If it wasn't for the Open Source Initiative you wouldn't be talking about Open Source or using it to describe software.
They can't stop other people from describing their own software, distributed as source code, as open source
They can and have pressured people who have abused this term to mean something other than what it does before, and the offencind parties have generally changed their license or stopped usign the term incorrectly. The only reason Open Source isn't a trademark is that this would require the OSI to police unauthorized use and approve the use of the term every time it is used to maintain the tradmark, which would be a waste of resources. This doesn't give you a license to make a closed source license like mplayer as Open Source because you get the code. By this logic, Pine, Qmail, and Windows 2000 are all Open Source because you can get code. In all cases (just like mplayer's) you can't do much with it. Its just that the authors of these tools don't tell people their apps are Open Source when they are clearly not.
though perhaps they have some claim to Open Source(tm)
As said earlier, there is no Open Source trademark. If you're knowledgable re licensing it surprises me you don't know that.
- although clearly some idiots would like them to have that power.
Yes, just because a bunch of people created a term, a definition of the term, an organization to support and promote the use of that term, certification tests for that term, and allow people who make software available under that definition to use that term doesn't mean they know anything about that term, certainly less than some troll on IRC who's likely an mplayer developer.
Photoshop for OS X
[OS X (Apple)] Posted by michael on Sun February 24, 06:21 AM
from the brighter-colors-and-whiter-whites dept.
MolGOLD writes: "Well, finally OS X users are getting their wish: Adobe has finally made good on their promise to bring native OS X support to their graphical applications. C|Net is running a story on the upcoming version of Photoshop, which will feature native OS X support. Now that Photoshop 7 will run natively under OS X, will we see companies like Macromedia (who also promised native OS X support) hurry along to follow suit?"
The 'Open Source Definition' isn't the be all and end all of what is and isn't open source
Yes, it is. It is the definition, oddly enough, of Open Source. By the people who invented the term, the Open Source Initiative. The MPlayer list license not on the OSI list of approved Open Source licenses, and many licenses with similar restrictions have been refused approval for the list. MPlayer is not Open Source as it doesn't meet criteria 2 of the definition. If it applied for OSI Certification, it would be rejected.
Read the Open Source Definition sometime, specifically criteria 2. Mplayer isn't Open Source, and has never been
I don't think the person who wrote this has much of an idea about using Linux on the desktop either.
Which file formats is he talking about?
The situation looks pretty good in my opinion for Linux to play 98% of what every desktop user wants to play.
Problem file formats
Don't you mean Koding with Kparts?
;).
Maybe not
Me>> Scanning for and removing mail viruses should be handled by your mail gateway (as well as your desktops for the following reasons).
:).
But what about other ways for virii to enter the network? Not everything comes in via POP/SMTP.
Yes. That's why I just said that
Add the following lines to your sources.list
And if you still don't have apt-get, then visit Freshrpms, download it, use it, and wonder how you ever got along without it.
PS - If any of you have the bandwidth to host a publically avaliable apt repository for Red Hat, then please post to the freshrpms mailing list and tell us all about it.
Scanning for and removing mail viruses should be handled by your mail gateway (as well as your desktops for the following reasons).
1) This way viruses are removed from your network at first opportunity
2) You can bounce messages and let the sender / recipient / admin know the sender has a potential virus problem
3) One server is easier to maintain than a few hundred desktops
3) 2 layers provide more protection than one
4) Why waste resources getting virus laden enail to desktops? A mail gateway provides a convenient choke point to get this stuff out of your network ASAP.
With that in mind here's a guide I wrote for my employer for doing so at clients, using Red Hat Linux, Postfix, and Sophos MailMonitor.
In the setup outlined below,
1) Postfix accepts incoming mails on port 25 and leads them to a content_filter.
2) The content_filter is Sophos MailMonitor, which takes over the mails on port 10025. After the mails have been scanned, they are placed back to postfix on port 10026.
3) Finally postfix delivers the mails.
Anyway, you should be able to read the guide at my rather unfinished website in a short while. If it isn't there yet, it will be soon.
The dependency and dependency resolution system- dpkg has the most advanced dependency system known to unix. No dobut to that... To solve these dependencies, dpkg goes to it's list of package locations (complete with http and ftp locations, cdroms, etc.. if necessary) and grabs the required packages from the net (the user is prompted on this, of course)
Dpkg doesn't do that. APT does. Its not that these aren't great and massively useful features, its just that just like urpmi, APT works its magic across RPM (the LSB standard packaging system, which many app packagers primarily package for) too. I maintain an apt repository for my workplace with around 3000 packages, all in RPM format for Red Hat 7.2, and it works like a charm. Debian's policies are postable too - Connectiva has a similar set of guidelines. The unique advantages of Dpkg is suggested / recommended dependencies, something RPM desperately needs (Red Hat themselves cheat and use the `comps' file to provide this logic themselves in the installer, but us users don't have the luxury). RPM has some unique advantages too tho - transaction handling in the database (thanks to DB3) does wonders for my piece of mind. In the end, I'll stick with RPM and Apt-get because of the LSB stuff, and avaliability, but I do hope they add suggested / recommended dependencies soon.
Actually, if you want to see a system which kicks both their arse in many ways, look at QNX. They have apt-like features, a nifty `package filesystem', and a GUI installer that reallycraps all over every other software install system I've ever seen.
Why not use the standard tools we're already using today... autoconf, m4, automake, libtool.. and have them build a "standard" config file for us at configure/build time?
Probably because a lot of the configuration files which are editied by m4 aren't considered human readable.
This is informative? Its demonstrably incorrect for one thing, about both the FHS and how packages are handled by Alien. Problem: the people who read (and moderate) Debian stories are the ones interested in Debian to the point of excluding anything that seems counter to the direction of their distribution.
Oh well, I guess I was never going to get much of a chance.
Please don't confuse what you want the LSB to be with what the LSB is. Debian is a full member of the LSB, the packaging decision was made with Debian's approval, and it has always been understood that Alien is an acceptable solution.
/usr/share/doc too. Its nice that everyone's actually uses the directory, rather than installing them into /var/cache/docs and saying they `support' /usr/share/doc is that's what you want to use.
I see this as a conflict within the LSB. Obviously a system which turns packagines into dumb archives is not a packaging system. Even if you said alien supports RPM installs, (I think the `P' and `M' is prettty debatable) it certainly doesn't do them well. Every Debian user I know of including myself wouldn't install a large volume of packages in standard format on a Debian box.
This is a bug withihn the LSB generated to satisfy Debian users. A rather unfortuinate compromise that will olikely bite either the LSB or Debian at some point in the future.
You're wondering if a guide to using software shoudl include instructions about installing that software: yes it should. Next question.
Yeah, I like
Your argument regarding changing is completely illogical. What is preventing you from changing? Just change within the standard. Policy is portable, APT already exists on RPM and I'm sure suggested/recommended dependencies woildn't be hard to implement. For servers and wrokstations, Linux should be Linux. If you want to make it something else, you have the option, but by default, it should support LSB standards in their entirety and reliably.
I don't know why you think its bad for Debian to provide their packages in .deb format.
Because Debian doesn't allow one to install a standard package and have that package work with ither software. This means a whole bunch if unecessary effort. As I've said earlier, and you've said yourself, policy has nothing to do with rpm or deb. Policy would be applicable to a LSB based Debian as well. In fact, this policy should be moved into the LSB - that's the best place for it. If one distro isn't allowing a et of packages to be installed because it causes some kind of problem, it sounds like all distros could benefit from that information. This should be obvious.
Please note that Debian and therefore DEB is older than Redhat or SuSE, AFAIK.
AFAIK that's not correct, RPM is the older system, but I can't find a URL. Not that age has anything to do with this.
Hopefully, perhaps inevitably, C++ libraries will be included as part of the LSB.
/etc/applnk directory.
Debian does great work to make sure that everything supports the Debian menu system, for example, and any problems with the software can go through one main bug tracking system.
Either of these are still entirely possible while using standard packages. One can track . Almost every other Linux distribution has its own version of the menu system, typically
Getting a large piece of software like KDE working right on your distribution can take quite a bit of work.
This is precisely the problem the LSB was created to solve. Linux apps should be Linux apps.
If you want to write an LSB program, then the LSB is there for you, and Debian will support that.
Not unless I make alien work as a package manager rather than an extractor of archives.
>> A standardized packaging system is useful for more than just closed source apps - its useful for every open source app maintainer
That's what "configure; make; make install" is for.
How? How will that solve the LDP from having to write twelve million different guides to ppp because some distro decided to use a nonstandard initscript dir, packaging system, or documentation directory? It won't.
You can't tell everyone to use the same language so we don't need to translate
Nobody is forcing people to do anything. Linux distro's, if they want to label themselves LSB, should do their best to support the LSB. The current abilities of alien seem to be highly lacking in this regard. If Debian don't want stable and reliable way of installing LSB packages, they should stop hoping inanely that the packaging system decision will be reversed and simply say they have no interest in the LSB, as Slackware does.
The thing is, I believe, that if the package format were the only difference, the RPM-or-DEB issue would be moot. The reason why Debian use its own packaging scheme, and IMHO what makes it far superior than RedHat and others when it comes to install or upgrade things, is the Debian Policy.
Indeed, the Debian policy is similar - is there any reason that it wouldn't be largely portable to RPM? Conectiva (which uses standard packages) already uses Debian policy as a basis for its own packaging guidelines.
It seems that you misunderstand - Alien works great, it makes RPMs, DPKGs, and TGZs interchangeable.
/etc/init.d. Other locations are not correct. Red Hat, SuSEm and other people who once put initscripts in other (now incorrect) locations are moving towards this.
/usr/doc files into /usr/share/doc, and haven't used /opt in years. Suse moved their initscripts from /sbin/init.d to the proper location, but still /opt kde. I'm glad that these efforts are being made, however greater effort on fundamental issues like the packaging system needs to be performed to stop Linux fragmenting.
.TGZ archives
.deb provides this. So is transaction handling for the rpm database - its good that rpm provides this. They each have their advanatges. I'd like to see the good features of deb added into RPM, and the LSB updated to this new version.
Your problem comes from the fact that Redhat RPMs (like Debian DPKGs and Slackware TGZs) also contain control information.
Of course they provide control information - if they didn't, they wouldn't be management systems would they? If alien still removes this information it does not do a good job of installing packages. Rather it turns those packages into dumb archives.
Since Redhat and Debian (all releases) use differnt locations for e.g. their rc.X files (initscripts)
Initscripts live in
AFAIK, the RPM standard is specified only in the FHS, and not directly in the LSB.
It seems you're in error. RPM 3 format packages are specified in the Linux standards base.
DJB has a number of valid criticisms [cr.yp.to] (of the FHS) that are as of yet not addressed by the LSB, or more accurately, the FHS.
Good or bad, its a standard. You'll get more pain from not sticking to a standard and fragmenting Linux than you will from adopting a standard even if you don't like every part of it. Some of DJBs recommendations (eg, a registered namespace for apps) coudl easily be included in the LSB, just as suiggested / recommended dependcies could be added to RPM if so desired (says someone who happily maintains a 3GB APT repository filled wit h RPM packages for the Red Hat machines at his workplace).
in fact the Debian Project has made FHS support a specific requirement [debian.org] in their official policy manual.
Excellent. But they really should do the same with the LSB.
The part of the FHS that you seem to be missing, is that while RPM is the official packaging format of the FHS, that doesn't mean that Redhat is automatically compliant.
True, another poster made this point earlier and I agree: all Linux distribtions should completely support RPM 3.05 packages.
Offical standard RPMs are handled by Debian via Alien flawlessly
No they are not, if they remove control information as you have earlier stated. Without this data there is no `management' and it seems alien can hardly be trusted to install a large amount of interdependent software.
Debian's pretty good with FHS support, so is RH: RH has likewise moved all
Theoretically, software developers should only have to release their files as
If they added standardized installs, uninstalls, information about the relationships between packages, querying / verifying machinisms, etc, this would be possible. Unfortunately they don't and it isn't: hence the need for packaging.
As a Red Hat user, it it is unfortunate but understandable that you didn't know more about the FHS and APT when you administered the Debian boxen.
I am well aware of the FHS and APT. I am well aware alien doesn't handle RPM packages beyong turning them into dumb archives. I just wanted to se if there is any attempt under way to fix this.
I'm also especially aware of how APT works: I run an APT repository for the Red Hat systems at work and my own machcine, with around 3000 packages.
Even if you had the FHS compliant rp-pppoe.RPM, using the APT/.dpkg version would be preferred, as the DPKG format has superior dependancy handling.
There are no `APT' packages - you means debs. APT run on top of the packaging system. Yes, recommended / suggested dependencies are very useful, and its good that
I am heartened to see that you haven't been down modded, I I hope that my post has been informative.
Thankyou.
Mike
-castlan