There's this really cool chat app for Windows I'd like to see on Linux, but that's never going to happen unless it's via Wine, and in fact I'm friends with the author and am trying to make it work via Wine for him. So scratch that vendor.
Hmm. The software my employer is writing I'm also porting to Linux (via Wine again). So that vendor is out.
The guys who make our dirt cheap ADSL modem don't provide a Linux driver for the USB version, but they do for the PCI version, so the lack of a USB driver is probably more to do with the fact that writing binary only drivers on Linux is a PITA, arguably they already support it.
nVidia do. I don't use any Windows-only apps any more. Microsoft won't listen.
The main difficulty is that often when I've talked to application vendors, they DO want to support Linux because they think it's growing, they think it's cool, their competition does - but can't economically justify it yet, or they don't have the expertise necessary to do so. Well, those two problems are only solvable by expanding the user base, which we are already working hard at.
So, it's not really a case of if we whinge enough we'll get support, maybe for some companies that's true, but I can't think of any I've dealt with lately that have really been hostile to the idea.
You honestly think one can't do buisiness using a Macintosh?
Yes. I have yet to see a business of any decent size run only on Macs. I'm not talking about one off small business ops where the IT manager is a Mac fanatic, I'm talking about companies with >100 employees for instance, and that isn't entirely media based. Ie virtually all companies.
There is certainly Mac software to fill about any need you can think of, and free high quality development tools just in case you find the odd thing that someone isn't currently supporting on the Mac.
The odd thing?? I don't think you quite realise the scale of most businesses dependancies on MS only software. Many (most?) companies have in house software that is either a one-off for them, or is highly vertical market. I'd guess virtually all such companies have the odd MS Access database floating around.
In short, no matter how well you can read MS Office files, or talk to NT network shares, no matter how lickable your UI, it comes down to the same thing it's come down to for the last decade - applications. That's what we have platforms for. Most businesses get their monies worth.
True Apple does have licensing as well, but it's not near as arduous as Microsoft's, that and Apple supports open source far more than Microsoft ever has or ever will.
Do you seriously believe Apple is a "nicer" company than Microsoft? You know what? They both have shareholders to please, they do what is financially expedient at the time. If it had been different and the positions of Microsoft and Apple were reversed, I can so see Gates co-operating with open source: he's a businessman.
Trusting Jobs to be "nicer" than Gates is asking for a slit throat.
your support costs are a lot less given that Mac's don't break down near as often as PC's.
That's just FUD, sorry. People persist in believing that Macs are inherantly more robust, or easier to use or whatever because they are never tested in the fiery pits of an IT dept with over 1000 users - wear and tear affects any technology, no matter how robust.
Windows has such enormous inertia something that's just like it but that looks different will never shift it, not even a little bit. Apple knows this, Jobs knows this, which is why they've relentlessly refocussed on personal use, even letting the education market drop. If they can see it, why can't you?
Yeah, support for various versions of glibc 2.3.x is in the new release (not actually on the website yet, but you can download it if you check the announcements list)
Maybe this disruption of MPlayer development can also be seen as a chance for a more unified default mediaplayer for linux, i.e. xine.
Hrm, be careful what you wish for. Xine may be nicer than MPlayer codewise but IMO GStreamer is nicer than Xine, as well as being powerful, with lots of promise.
There are still some things that need to be done with GStreamer before you could say recreate Xine - it needs interactivity support for DVDs etc.
Long term though it's pretty obvious that Xine and GStreamer are going to compete for the multimedia framework - I have no idea if that's bad or good.
Well, from my perspective if it's a platform then really it needs to be Free these days, at least in computing - I couldn't give a rats ass about word processors as long as you can read their file formats, or photoshop, or photoshop plugins etc etc because the companies involved have to rely on the merits of the product to sell them, rather than network effects.
It's difficult to decide here whether in this context WMV is a platform or not. I rather suspect it is.
Re:Legacy-free computing? Apple's way ahead, as us
on
Legacy-Free PCs
·
· Score: 1
See a trend here? Seems the x86 world is just now getting around to solving legacy issues that Apple solved long ago. Welcome to the future, folks.
I don't really understand how needing to run a virtual machine for old OS 9 apps isn't considered a "legacy issue".....
Re:Let's hear it for legacy free!
on
Legacy-Free PCs
·
· Score: 1
I think you missed the sentance that said, "The ones that do, do so at exorbitant prices."
Re:We can have a PC not based on twenty year old t
on
Legacy-Free PCs
·
· Score: 1
A legacy free OS is about as useful as a legacy free automobile.
I think it's safe to assume that in this context, legacy free actually means cruft free.
Not really, file deps have quite a lot of problems, for instance, they are not portable (debian has problems importing them) and they assume that every file has a standard place, which of course isn't the case.
File deps lead to big problems further down the road because you effectively end up managing a namespace of every file on the system, instead of every package. Every package is hard enough thanks!
File deps can be useful when carefully used, but at least in my opinion package based dependancies have merits that shouldn't be overlooked as well.
Claiming that an RPM that doesn't use file deps is done incorrectly is a bit harsh on the packager, perhaps file deps work OK for perl, but they are not the be all and end all of dependancy management, far from it.
The article states that "if application writers followed the guidelines provided by the LSB, you would not have dependency problems".
Yes, slightly misleading IMO, the LSB currently says you can only have 1 dependancy, on the LSB itself, so presumably he meant "if they followed the guidelines provided by the LSB, you would not have dependancies". That's one way to solve the problem. It's not a very good way though.
I don't see how any guidelines would change the fact that the non-RH RPMs are based on older libraries, (or newer, as the case may be). That is by far the biggest problem.
Not really, in theory this shouldn't be any problem. If an older library has broken its ABI, soname versioning means it's parallel installable. If it hasn't, then it's backwards compatable and stuff should just work. If a library a package depends on is newer, the packaging system should be able to upgrade or install a newer version automatically.
That's the theory. In practice, for a variety of reasons ranging from naming issues to deep-code glibc problems, it doesn't always work. These are known issues, but fixing them is, as you might imagine, a lot of work.
I wanted Eterm on my RH8.0 install, couldn't find any RH packages for it, so I tried a generic one. It depended on some Perl modules, no big deal. I grab those -- one module depended on an old version of Perl (it would only accept that version).
I'm not sure why Eterm needed Perl, I've installed Eterm onto Redhat with no problems like that. But regardless, this is more an artifact of the general brokenness of Perl - if it breaks backwards compatability, then it should provide a "legacy" mode or allow two versions of perl to be parallel installable. Thankfully instances of conflicts like this are relatively rare.
Which brings us to another problem. All the RPM distros I've seen have big version differences in all their 'releases'. Which makes it hard for developers to release packages for the distro. They need one for 7.x, 8.x, etc.
Well, the reasons behind needing new packages for each version vary.... in fact, I suspect a lot of packages meant for rh8 will work on rh9, but YMMV. Major version number increases usually signify that something broke backwards compatability, but it's very vague.
In reality though, if you know what you're doing you can make portable packages - Loki did, CodeWeavers do etc etc. In the case of Loki, in fact they compiled on a Redhat 6 setup if I recall correctly. Obviously they are pretty self contained, but things like the LSB can help people produce portable binaries. It doesn't (yet) address other packaging concerns.
Kinda ironic that the Linux distribution everyone loves to hate, Lindows, worked right out of the box when Red Hat 9 failed miserably.
Not really. Linux is a large software project. Regressions happen. This is more a problem with XFree than Redhat especially, it's just that Lindows use ancient versions of everything.
Just to add to that, if you pull Wine CVS you need to compile with the --with-nptl option - the intention is for it to become detected at runtime so the configure option will die, but for now that's your best bet.
Careful, as already pointed out, there's nothing illegal about it - corporates can't make laws fortunately, it is however perhaps slightly immoral, they want people to pay for that priviledge:)
Wired Networking:
Apple - 10/100/1000
Dell - 10/100
Winner: Apple
You do realise that practically nowhere offers gigabit ethernet plugin at the wall, not even at work? It's mostly for wiring up server farms etc. I seriously doubt your computer can consistantly give a gigabit of throughput anyway - this is like when they bumped the ram up to DDR, who cares that the CPU couldn't actually use it, it made the specs look better!
In summary, while the PC is a little bit cheaper and the processor a little faster, in virtually every other area the Mac comes out ahead.
Uh, no it doesn't. You forgot things like:
Application/games compatability:
Dell: virtually everything,
Apple: almost nothing (statistically speaking)
Choice of hardware:
Dell: everything
Apple: little
Sure the processor may be a little bit slower, but it isn't a dramatic difference
Isn't a dramatic difference? What rock have you been living under for the past few months? The P4 smokes the G4, and given that MacOS is notoriously inefficient with CPU cycles, it puts the Dell even further ahead. Comparing a decidedly middle of the road Intel processor with the high-end Mac CPU is hardly fair is it?
This is just so classic product psychology - desperately attempting to justify the purchase of a product by fiddling with numbers and product comparisons. If you like it, that's cool - you don't need to justify that to anybody. If you're having doubts, then posting ridiculously biased comparisons isn't going to help.
It seems apple's strategy might be to FORCE us to switch... Sounds almost like something MS would do.
Ah, but switch to a Mac, or switch to another audio program?
I'd go for the latter. Screwing over a large part of a customer base you just aquired does not bode well for the future, and VST really isn't that bad.
OpenOffice is enormous. The code is mindboggling. It has its own portable runtime, its own object model, its own widget toolkit. It's like Mozilla.
You can't "port" it to KDE, any more than you could port it to GTK/GNOME. What Ximian have been doing lately is simply touching up the edges, making it use the same font/colors as GTK, use GNOME artwork etc, but it's not a "port".
[soapbox]The original KDE vision of producing an integrated desktop through making kickass APIs that everybody would use was a cute one, but ultimately short sighted - your average Linux desktop is a mishmash of different platforms and toolkits, KDE, GNOME, OpenOffice, Mozilla, Wine - there's no way all this sofware can be ported to KDE, so the only solution is to eliminate the idea of KDE/GNOME as a platform and become based entirely on standards, with KDE merely providing an implementation via C++ APIs.[/soapbox].
As pointed out in an above post, there are experiments with using Wine to let Linux apps use Windows VST plugins, in a similar fashion to how mplayer allows you to use Win32 codecs. That's one of the cool things about Wine. It lets you do seamless integration.
Anyway, I expect the next problems once VST compatability is conquered will revolve around making sequencers comparable in power - for various reasons I think VST itself won't run under Wine (needs the windows equivalent of kernel modules?). Oh yes, and file format compatability as well.
ASIO is a Windows specific hack around the lack of low latency audio on that OS I think, so it doesn't apply to Linux/ALSA which has some of the lowest latencies around with the right kernel patches.
I may be wrong, but whatever. It seems to me that Linux *really* needs a decent stream mixer.
Well the ALSA guys are working on that in the form of the dmix plugin for libasound, that mixes in the DMA buffer.
So, anyone know a soundcard that will let me play mutiple streams WITHOUT having to use esd/artsd, and is decently well supported under Linux? Anyone? BTW, can we keep it under $100 (USD) if possible?
All you need is one that supports hardware mixing. They aren't necessarily expensive but are getting hard to find, sounds cards are like modems these days, many manufacturers shift the processing onto the CPU via Windows:(
The most amazing thing about the Linux audio scene is how well organised it's been since day one. All the key players work together, and are putting together a seriously sweet pro audio architecture. The same people who write ALSA collaborate on Jack, LADSPA (which looks like an open alternative to VST plugins), write sample editors - the works.
It's too bad that the desktop audio scene is such a shambles by comparison - in 2003 there is still no standard way of mixing and resampling (sound servers). What I expect will happen at this point is simply that once 2.6 is rolled out, distros will simply start shipping with the ALSA dmix plugin which mixes at the hardware level by writing into a sound cards DMA buffer (iirc), making most desktop uses of sound servers obsolete (though they can still be useful for network transparent audio and jack style synchro).
Oh, and GStreamer kicks ass:) It's messy right now, but I think Linux multimedia could become really great.
I wouldn't even concider another vender now unless they could demonstrate the dedicacion to the *nix world that nVidia has.
Hmm, Matrox? Bear in mind that Matrox release high quality documentation for all their cards, have donated hardware to driver writers before and so on. That's why the Matrox drivers are generally high quality, get all the cool new features from X and DirectFB first and (more importantly) work out of the box on new systems.
To be honest, if I was going to build hardware specifically to run Linux, I'd probably use Matrox cards. Freedom of information is what this 'revolution' is really about. That's not to say nVidia are a bad company - from what I understand their hands are tied by the use of patented tech like texture compression, and obviously for people who don't choose their own GFX cards (like this work machine I'm using now for instance, which is nvidia) the fact that the company is so good at writing drivers is a blessing.
Anyway, it's cool to see people taking the initiative with Linux installation technology. The Loki installer is quite old now, but we've derived great inspiration from it for autopackage - we're aiming for similar plug and play "it just works" installs for all packages in future.
Slashdot Mirror
One problem. I'm struggling to think of a vendor.
There's this really cool chat app for Windows I'd like to see on Linux, but that's never going to happen unless it's via Wine, and in fact I'm friends with the author and am trying to make it work via Wine for him. So scratch that vendor.
Hmm. The software my employer is writing I'm also porting to Linux (via Wine again). So that vendor is out.
The guys who make our dirt cheap ADSL modem don't provide a Linux driver for the USB version, but they do for the PCI version, so the lack of a USB driver is probably more to do with the fact that writing binary only drivers on Linux is a PITA, arguably they already support it.
nVidia do. I don't use any Windows-only apps any more. Microsoft won't listen.
The main difficulty is that often when I've talked to application vendors, they DO want to support Linux because they think it's growing, they think it's cool, their competition does - but can't economically justify it yet, or they don't have the expertise necessary to do so. Well, those two problems are only solvable by expanding the user base, which we are already working hard at.
So, it's not really a case of if we whinge enough we'll get support, maybe for some companies that's true, but I can't think of any I've dealt with lately that have really been hostile to the idea.
Yes. I have yet to see a business of any decent size run only on Macs. I'm not talking about one off small business ops where the IT manager is a Mac fanatic, I'm talking about companies with >100 employees for instance, and that isn't entirely media based. Ie virtually all companies.
There is certainly Mac software to fill about any need you can think of, and free high quality development tools just in case you find the odd thing that someone isn't currently supporting on the Mac.
The odd thing?? I don't think you quite realise the scale of most businesses dependancies on MS only software. Many (most?) companies have in house software that is either a one-off for them, or is highly vertical market. I'd guess virtually all such companies have the odd MS Access database floating around.
In short, no matter how well you can read MS Office files, or talk to NT network shares, no matter how lickable your UI, it comes down to the same thing it's come down to for the last decade - applications. That's what we have platforms for. Most businesses get their monies worth.
True Apple does have licensing as well, but it's not near as arduous as Microsoft's, that and Apple supports open source far more than Microsoft ever has or ever will.
Do you seriously believe Apple is a "nicer" company than Microsoft? You know what? They both have shareholders to please, they do what is financially expedient at the time. If it had been different and the positions of Microsoft and Apple were reversed, I can so see Gates co-operating with open source: he's a businessman.
Trusting Jobs to be "nicer" than Gates is asking for a slit throat.
your support costs are a lot less given that Mac's don't break down near as often as PC's.
That's just FUD, sorry. People persist in believing that Macs are inherantly more robust, or easier to use or whatever because they are never tested in the fiery pits of an IT dept with over 1000 users - wear and tear affects any technology, no matter how robust.
Windows has such enormous inertia something that's just like it but that looks different will never shift it, not even a little bit. Apple knows this, Jobs knows this, which is why they've relentlessly refocussed on personal use, even letting the education market drop. If they can see it, why can't you?
And for those who like to put names to faces, here are some photos of the happy chappies who make Wine great
Yeah, support for various versions of glibc 2.3.x is in the new release (not actually on the website yet, but you can download it if you check the announcements list)
I'm pretty sure that hasn't been true for a while - the opt scheduler took care of that stuff.
Hrm, be careful what you wish for. Xine may be nicer than MPlayer codewise but IMO GStreamer is nicer than Xine, as well as being powerful, with lots of promise.
There are still some things that need to be done with GStreamer before you could say recreate Xine - it needs interactivity support for DVDs etc.
Long term though it's pretty obvious that Xine and GStreamer are going to compete for the multimedia framework - I have no idea if that's bad or good.
I believe it is yes, at least in RPMv3, which is what the LSB specifies. The glibc symvers thing is partly what the LSB is for.
It's difficult to decide here whether in this context WMV is a platform or not. I rather suspect it is.
I don't really understand how needing to run a virtual machine for old OS 9 apps isn't considered a "legacy issue".....
I think you missed the sentance that said, "The ones that do, do so at exorbitant prices."
I think it's safe to assume that in this context, legacy free actually means cruft free.
File deps lead to big problems further down the road because you effectively end up managing a namespace of every file on the system, instead of every package. Every package is hard enough thanks!
File deps can be useful when carefully used, but at least in my opinion package based dependancies have merits that shouldn't be overlooked as well.
Claiming that an RPM that doesn't use file deps is done incorrectly is a bit harsh on the packager, perhaps file deps work OK for perl, but they are not the be all and end all of dependancy management, far from it.
Yes, slightly misleading IMO, the LSB currently says you can only have 1 dependancy, on the LSB itself, so presumably he meant "if they followed the guidelines provided by the LSB, you would not have dependancies". That's one way to solve the problem. It's not a very good way though.
Not really, in theory this shouldn't be any problem. If an older library has broken its ABI, soname versioning means it's parallel installable. If it hasn't, then it's backwards compatable and stuff should just work. If a library a package depends on is newer, the packaging system should be able to upgrade or install a newer version automatically.
That's the theory. In practice, for a variety of reasons ranging from naming issues to deep-code glibc problems, it doesn't always work. These are known issues, but fixing them is, as you might imagine, a lot of work.
I'm not sure why Eterm needed Perl, I've installed Eterm onto Redhat with no problems like that. But regardless, this is more an artifact of the general brokenness of Perl - if it breaks backwards compatability, then it should provide a "legacy" mode or allow two versions of perl to be parallel installable. Thankfully instances of conflicts like this are relatively rare.
Well, the reasons behind needing new packages for each version vary.... in fact, I suspect a lot of packages meant for rh8 will work on rh9, but YMMV. Major version number increases usually signify that something broke backwards compatability, but it's very vague.
In reality though, if you know what you're doing you can make portable packages - Loki did, CodeWeavers do etc etc. In the case of Loki, in fact they compiled on a Redhat 6 setup if I recall correctly. Obviously they are pretty self contained, but things like the LSB can help people produce portable binaries. It doesn't (yet) address other packaging concerns.
Not really. Linux is a large software project. Regressions happen. This is more a problem with XFree than Redhat especially, it's just that Lindows use ancient versions of everything.
Good luck -mike (with my wine developers hat on)
Careful, as already pointed out, there's nothing illegal about it - corporates can't make laws fortunately, it is however perhaps slightly immoral, they want people to pay for that priviledge :)
You do realise that practically nowhere offers gigabit ethernet plugin at the wall, not even at work? It's mostly for wiring up server farms etc. I seriously doubt your computer can consistantly give a gigabit of throughput anyway - this is like when they bumped the ram up to DDR, who cares that the CPU couldn't actually use it, it made the specs look better!
Uh, no it doesn't. You forgot things like:
Application/games compatability:
Dell: virtually everything,
Apple: almost nothing (statistically speaking)
Choice of hardware:
Dell: everything
Apple: little
Isn't a dramatic difference? What rock have you been living under for the past few months? The P4 smokes the G4, and given that MacOS is notoriously inefficient with CPU cycles, it puts the Dell even further ahead. Comparing a decidedly middle of the road Intel processor with the high-end Mac CPU is hardly fair is it?
This is just so classic product psychology - desperately attempting to justify the purchase of a product by fiddling with numbers and product comparisons. If you like it, that's cool - you don't need to justify that to anybody. If you're having doubts, then posting ridiculously biased comparisons isn't going to help.
Ah, but switch to a Mac, or switch to another audio program?
I'd go for the latter. Screwing over a large part of a customer base you just aquired does not bode well for the future, and VST really isn't that bad.
OpenOffice is enormous. The code is mindboggling. It has its own portable runtime, its own object model, its own widget toolkit. It's like Mozilla.
You can't "port" it to KDE, any more than you could port it to GTK/GNOME. What Ximian have been doing lately is simply touching up the edges, making it use the same font/colors as GTK, use GNOME artwork etc, but it's not a "port".
[soapbox]The original KDE vision of producing an integrated desktop through making kickass APIs that everybody would use was a cute one, but ultimately short sighted - your average Linux desktop is a mishmash of different platforms and toolkits, KDE, GNOME, OpenOffice, Mozilla, Wine - there's no way all this sofware can be ported to KDE, so the only solution is to eliminate the idea of KDE/GNOME as a platform and become based entirely on standards, with KDE merely providing an implementation via C++ APIs.[/soapbox].
Anyway, I expect the next problems once VST compatability is conquered will revolve around making sequencers comparable in power - for various reasons I think VST itself won't run under Wine (needs the windows equivalent of kernel modules?). Oh yes, and file format compatability as well.
ASIO is a Windows specific hack around the lack of low latency audio on that OS I think, so it doesn't apply to Linux/ALSA which has some of the lowest latencies around with the right kernel patches.
Well the ALSA guys are working on that in the form of the dmix plugin for libasound, that mixes in the DMA buffer.
So, anyone know a soundcard that will let me play mutiple streams WITHOUT having to use esd/artsd, and is decently well supported under Linux? Anyone? BTW, can we keep it under $100 (USD) if possible?
All you need is one that supports hardware mixing. They aren't necessarily expensive but are getting hard to find, sounds cards are like modems these days, many manufacturers shift the processing onto the CPU via Windows :(
It's too bad that the desktop audio scene is such a shambles by comparison - in 2003 there is still no standard way of mixing and resampling (sound servers). What I expect will happen at this point is simply that once 2.6 is rolled out, distros will simply start shipping with the ALSA dmix plugin which mixes at the hardware level by writing into a sound cards DMA buffer (iirc), making most desktop uses of sound servers obsolete (though they can still be useful for network transparent audio and jack style synchro).
Oh, and GStreamer kicks ass :) It's messy right now, but I think Linux multimedia could become really great.
See here for info on getting transparent PNGs working in IE.
Hmm, Matrox? Bear in mind that Matrox release high quality documentation for all their cards, have donated hardware to driver writers before and so on. That's why the Matrox drivers are generally high quality, get all the cool new features from X and DirectFB first and (more importantly) work out of the box on new systems.
To be honest, if I was going to build hardware specifically to run Linux, I'd probably use Matrox cards. Freedom of information is what this 'revolution' is really about. That's not to say nVidia are a bad company - from what I understand their hands are tied by the use of patented tech like texture compression, and obviously for people who don't choose their own GFX cards (like this work machine I'm using now for instance, which is nvidia) the fact that the company is so good at writing drivers is a blessing.
Anyway, it's cool to see people taking the initiative with Linux installation technology. The Loki installer is quite old now, but we've derived great inspiration from it for autopackage - we're aiming for similar plug and play "it just works" installs for all packages in future.
keep on truckin'
-mike