I don't think BMW has ever complained about their 2% marketshare. Neither has Apple.
Cars aren't platforms - you can't compare the two. If an OS has no users, it has no apps and it will never get users - ie it is a dead OS. If a car has no drivers, it could still have 20,000 drivers tomorow, ie it's a "sleeping" car;)
OK, just make sure to use GTK# instead of S.W.F - gtk is a better toolkit anyway. Avoid the registry. Avoid Win32isms. Then it should be pretty portable.
Most irritating was GDM, which decided that if I pressed Ctrl-Alt-Backspace I really didn't want to kill X so I could install the NVIDIA drivers, I just wanted X to restart.
Um this is the correct behaviour in almost every circumstance. If you want to install the binary drivers you're supposed to drop to runlevel 3, this is even documented.
The alternative is that if the X server crashes, you get thrown to a blank text screen - I'd much rather be put back at the login screen. GDM is designed this way for good reasons, you know - in fact I think most display managers do this.
Actually I meant development processes - Wine the project as opposed to Wine the software (which you are right, runs acceptably well most of the time). Wine is moving faster than ever before and is one of the most active open source projects around, but more people are always needed. If there is a magic bullet we can use to increase participation, and increase the efficiency of those already taking part, that'd be a valuable thing indeed.
Unfortunately, nobody has yet come up with one.
It'd be really great to know what would encourage people to work on Wine, so we can help them. WineHQ is one of the friendliest communities that I've encountered, so I feel it has to be our processes or technologies (or maybe just the nature of the beast) that scare people off.
Re:Believe me, I love it as much as anybody, but.
on
WineConf 2004 Wrapup
·
· Score: 5, Informative
Mods, please ignore this post, it's just a troll. Wine doesn't even have a TCP/IP stack, it (of course) uses the underlying hosts stack, ie the Linux/FreeBSD/Whatever stack. "Wait states for unsupported hardware" is entirely meaningless, Wine does not have hardware support, again that's delegated to the underyling operating system.
Of course, if the poster can show specific sections of code he feels have "fundamental flaws" and describe them satisfactorily then I'll take my words back.
Sure. That doesn't work for shared libraries though, so it's only usable inside the primary binary.
The way binreloc works is by taking the address of an empty string symbol from the GOT then scanning linker maps in/proc/self/maps to find itself. This is 100% robust and works regardless of whether the code is used inside the executable or library. It also gives you an absolute path every time with no manipulation needed.
So the real question is, if it's so easy why doesn't glibc provide a function to do it for you?
Nah, you misunderstood what the guy was talking about.
On Windows, the linker records which DLL a symbol comes from and you can explicitly specify it in the source/header files using some simple language extensions. On Linux, that isn't done, and worse ELF specifies unscoped symbol fixup semantics.
To rephrase the original question: if libA1.so is linked against foo_func() in libA2.so, and libB1.so depends on foo_func() in libB2.so, and binary Z links against libA1 and libB1, then the results will not be what you expect. Both libA1 and libB1 will be linked to the foo_func() in libA1, because that came first in the load order.
This causes problems when different parts of the program use different versions of the same library - they may be independent parts of the code but the wires get crossed inside ld.so and things go boom.
It'll need to be fixed at some point. Using the ELF grouping extension in Solaris seems to make sense. Somebody just needs to write the code and (this is the hard part) get it accepted upstream.
So? Managed code is not the only way to eliminate buffer overflows. Go read up on exec-shield and PIE binaries to see another way that's being deployed on Linux right now.
It's not so much the location of the overflowed buffer that's the problem, it's the location of the GOT (or IAT on Win32) that matters, as that allows you to call any function imported by that binary. On Windows PE binaries usually have their relocation records stripped so they always load at 0x400000, making the IAT easy to access by an absolute jump. On Linux the situation is mostly the same, albiet with a different address, unless you are using Fedora Core 1 in which case exec-shield with PIE binaries are used to give binaries randomized load addresses. One of the reasons it's called exec-shield is because it helps reduce the problems of buffer overflows - at least it makes it harder to run useful code (you can still crash the app of course).
Well, Microsoft always claim that the reason it takes them so long to get security fixes out is because they have to QA it, make sure they don't break apps etc - but I really don't understand this. It's a buffer overrun. Change the code to calculate the size then use dynamically allocated memory and it's fixed, right? Worst case, put bounds checking in there. How on earth could this possibly even affect public API? How could this cause regressions in apps? If there are apps out there that break because of security fixes like this, why should we care? Isn't the security of millions more important than those crack-ridden apps?
Secondly, if I get an ELF executable in an email, I have to save it to disk, open a terminal, chmod +x it and then type in its name.
Nah. It's easy. Just stick it into a.tar file, call it "runme", mark it +x (tar preserves permissions). All modern desktops include a visual archive viewer like File Roller or ark, which allow you to open/run files direct from it. I don't know if you can run an ELF binary direct from file-roller, but I expect it's not too hard. Certainly most users, once tricked into wanting to run the file, could do it, especially as Linux desktops get more straightforward.
This prevents certain users from writing their own programs and scripts, but hopefully one would feel comfortable granting an exception for these more advanced users and giving them some space for programming.
noexec provides no security at all, any script or ELF binary can be run by using the appropriate interpreter. For most ELF binaries the interpreter is/lib/ld-linux.so.2, and it takes as an argument the binary to run.
This will lead to problems as the loader will load only ONE version of the library and require both a.out and a.so to use the same version of b.so. This is why rpm's of the same program are not compatible accross different versions of the same distro
Whoa, slow down. That's not right at all. Firstly, some RPMs are compatible across distributions, but not all - and it's basically hit and miss.
The linker fixup problems are one issue yes, but to be honest these occur rarely, especially once you start stripping unnecessary DT_NEEDED entries from your binary (unnecessary -lfoo options).
Eventually we'll need to change it to be more like how Windows does it, but it's not a high priority. Fixing build tools to not dump piles of bogus (in the case of recent toolchains) -lfoo options on the compiler is a more important issue, but I have no idea how to fix this in a general way. Possibly extensions to pkg-config would need to be made, certainly this is something that will require large-scale changes to peoples build systems.
I'm hoping that when autopackage is released and stable, it'll be so fantastically popular that it will motivate people to fix these myriad binary portability issues in their apps (and none of them are unsolvable or inherent in the way Linux works). We're writing a guidebook to help people do this, but it's not really released yet.
Maybe Apple can do this because they have a standardized directory structure
Nope, they can do it because they have a standardised platform. All MacOS X apps have at least one implicit dependency - on some version of MacOS. That one dependency is very easy (well, assuming you are rich) to satisfy, but it gives you a whole pile of functionality.
Because desktop Linux is evolving at such a rapid rate, and because nobody controls it, and because people like being able to control what's on their system to a fine degree, we have no such platform currently.
Unfortunately the first attempts at such a platform foundered when KDE made the bum choice of using a toolkit with a problematic license, so Gnome was started in reaction and now we have two, with neither being widely spread. The Gnome guys are busy moving infrastructure out into non-Gnome libraries like GTK, Cairo, DBUS etc that are explicitly designed to be acceptable to everybody, but unfortunately the KDE guys are still having big internal arguments about whether freedesktop.org (the new attempt) is "forcing" things upon them (see the discussions at kdedevelopers.org)
This is unfortunate because a standard platform that you could depend upon with only one dependency would go a long way towards making software on Linux easier to install.
Installation programs (like MSI files) are simpler, aren't they?
I think once you spent hours disassembling and debugging these "simple" installer programs to make them run on Wine you'd have a different view on the matter;)
Let's do a quick review of how things are done on Windows:
InstallShield/NSIS type installer programs. These embed all the data needed inside themselves, or in the case of InstallShield the actual installer is wrapped by the equivalent of a WinZip self extractor. Ever wondered why InstallShields take so long to start? Well, the first thing it does is extract a bunch of files (setup.exe, data.cab, some dlls etc) that comprise the installer, then it runs setup.exe which in turn extracts the InstallShield Engine to your local hard disk, possibly upgrading it in the process. Then it runs it and makes RPCs to it using DCOM, which starts the actual installation - done by iKernel.exe.
This is sort of how autopackage works, except we do it in a much simpler way and don't rely on CORBA (the nearest equivalent of DCOM on Linux). These installers have no dependency management beyond "is this file the right version? No? replace it then" which has caused some truly horrific hacks like Windows File Protection.
MSI packages. These are the closest Windows has to traditional RPMs/DEBs. You need to install the runtime support separately for MSIs to work. They are based on a bizarre kind of database, with its own dialect of SQL. MSIs are mostly data but are extendable via COM, iirc. They even deal with dependencies, via MSMs (merge modules).
MSIs "deal" with dependencies by including the least common ones inside themselves, causing huge and bloated downloads, and leaving the user to figure out random breakage for ones that don't exist (how many times have you found that an app assumes the presence of some VB/VC++ runtime lib that just wasn't there?).
They can get away with this because Windows is a platform and a whole pile of technology is guaranteed to be present. For instance, you know without needing to check that graphics support is available, because it's a part of the kernel and cannot be removed. On the server that's an achilles heel, on the client it's an advantage (in terms of packaging).
MSI/InstallShield hybrids. [shudder]. Let's not go there. These things take evil to a new level.
Zip files. All MS Windows binaries are relocatable. In contrast, virtually no Linux binaries are. That's partly because it's not at all obvious how to make them so - there is no glibc API available to figure out your absolute path, rather stupidly (and I'm too scared of Uli Drepper to submit one;). We wrote a simple dropin C file to help C/C++ programs do this - making a program relocatable makes many users lives a lot easier, so do it today.
Because there is no standard Linux platform (the LSB never caught on), and the user can basically arbitrarily add, remove or upgrade individual components as they see fit (from the kernel to the theme in use) package managers are used to manage and maintain it all. Unfortunately, because there is no standard platform, the distro becomes the platform - of which there are many.
The freedesktop.org platform effort and the LSB are both worthy steps forward in this area and I hope they pick up steam. In the meantime, approaches like autopackage, being dependency-smart and having communities of packagers are the way forward.
By the way, it's funny this should be mentioned now but autopackage.org is in the middle of a DNS repropogation - it was switched to point to sunsite.dk literally hours ago.
For now, if it doesn't work, use autopackage.sunsite.dk and bear with us as we fixup the broken links etc.
That's entirely different. Once *somebody* has decrypted an OpenPGP message they can distribute it with no problems.
DRM is not about strong encryption. DRM is about stopping you saving files to disk, sending them to friends, burning them to CDs. It's effectively about preventing you from moving data around like you can do normally.
I can't think of a good way to do open source DRM. You can put as much encryption as you like in, you could even do a Windows XP and encrypt audio right into kernelspace, but at the end of the day it's all just a few patches away from being intercepted easily. And once it's been intercepted, you can strip the DRM and move stuff around easily again.
Yeah. This is a tricky one. I'm not sure how it'll play out. Most likely if Linux has taken off by the time DRM gets big we'll just end up with binary, proprietary kernel modules and apps to do it. End of story.
Yeah. We've talked around this issue in autopackage, we had some plans for sandboxing and such but then I discovered SELinux and realised that this is probably a smarter way to do security on Linux. It it entirely capabilities based, so you can define exactly what a process (and it's children) can and cannot do. If you don't want an installer to be able to create suid binaries, you can prevent that.
At least this is the theory. I have no idea if SELinux actually is that fine grained, but I expect it could be made so if not. You could then assign sandboxed permissions to an installer.
One issue is that in autopackage each installer/.package file is actually what runs the installation process, there is no supervisor process like in RPM, so you'd have to remember to use one explicitly. While we could of course make a.package file surrender itself to such a supervisor process, that wouldn't be reliable as the code to do it could always be hacked out by the malevolent packager. An interesting problem for sure.
BTW I read and inwardly digested your other comments too. I'm still pondering them... it's certainly not a black and white issue.
It seems to me that our package managers (used by the majority of Linux users...not everyone compiles from source) are vulnerable to some type of subversion.
That's right. When you have piles of packages (source or binary) hosted on single servers run by the same group of people, you're making yourself a really tempting target. You don't even have to trojan a package - just find an exploit then DDOS the update servers so people can't access the fixed packages easily and you've bought yourself some time. As for large repositories of unsigned packages - let's not even go there.
There is no 'certificate' which can be attached to them to guarantee their purity. What the Linux community needs, I feel, is a type of central signing authority or cryptographically sealed DRM-compatible package management system.
No, the last thing Linux package management needs is more centralization. What we need is *less* centralization.
How many times have you heard of Windows users being compromised by trojaned InstallShield Wizards? I'm not talking about binaries a virus has infected, I mean bent installers. I've never heard of such a thing. Even if it has happened (and I expect it has a few times), it's a very hard way to infect somebodies system because you have to compromise a server, rebuild the installer somehow and then you only manage to get one package which may or may not be run by lots of people anytime soon.
What Linux package management needs to be more secure is for projects to host their own binary packages as they do for source packages. That way if/when breakins occur, the damage is at least limited.
And it would be impossible to accidently load and install a trojan.
I think this is wrong- if upstream is trojaned you are still screwed. Packagers don't audit the code, you know.
ldd on Linux systems uses a variant of the rtld debugging mode to print out the links. So the program does run, but it also doesn't, which is where I think the confusion comes from.
To be more specific, the kernel passes control via.interp to the rtld, which performs dynamic linkage (printing stuff out) but it never passes control to the entry point. So the original posters assertion that you need a separate test executable for ldd is entirely wrong, and shows only that he's never actually used the tool in question.
If you want an approach that works by reading the ELF binary directly try:
objdump -x foo | grep NEEDED
which will show direct links only, rather than ldd which shows every DSO mapped into the process image.
The rest of the *NIX development world would be much nicer if they adopted a similar scheme
You've got to be joking. You think Mach-O is superior to ELF or PE? No way joe, no way in hell.
Let's take a quick review of some of the more stupid parts of the MacOS X shared library/exec format systems:
Shared libraries can either be implicitly linked (-lfoo) or explicitly linked (dlopen) but not both. If you want both you have to build two separate versions of the library, keep them in sync, and double disk space/memory usage.
All systems (well, windows linux and macos x) have prebinding but the way it's implemented on MacOS X is rather unreliable
Pathetic versioning. Weak symbols were only fully deployed throughout Cocoa in 10.3, and large parts of the platform libraries still don't have them. This makes writing software which works on older versions of the OS while using features found in newer ones a complete pain in the ass - but surprise surprise this is what Apple wants, as that way they sell more upgrades.
Weak symbols blow. Windows used them back in the 3.0 days and it was removed, because too many developers got it wrong - it was simply impractical. Worse, the nature of the failure is unpredicatable: Fred App can run fine for an hour then mysteriously crash if the developer forgot to account for only 1 weak symbol (when a typical app can include tens of thousands). This was a real problem back before Windows 3.1 introduced a "no fixup, no run" rule.
Scary implicit upgrade/downgrade system. If an application in the same directory has a later version of a library, all apps in the same directory will use it while it's available. This allows one app to silently override the libraries used by other apps - DLL hell was bad enough but this simply boggles the mind. A badly written app that contained a broken/somehow incompatible library upgrade could mysteriously break and unbreak apps with no obvious cause.
No thanks. ELF is an extremely efficient and well designed format, with the only major wart remaining being the lack of a GNU implementation of grouped fixup - hardly a fault of ELF itself, thinking about it.
It's pretty much a superior setup to the average linux world. But then, we paid for something besides just iCandy, right?
That's pretty much classic product psychology. "I paid more for it, and my judgement is sound, so therefore it must be better".
In fact the reason MacOS X uses Mach-O is because it uses the Mach kernel, which it uses not through any technological superiority (in fact the going opinion these days is that mach is trash), but because they hired Avi Tanenbaum (sp?).
Preach it brother. I also bought a wireless card that I thought had an Atmel chipset. I dicked about with the two GPLd drivers, upgraded to 2.6 and still no dice.
Guess what? It turns out, after a quick email exchange with the authors of those drivers, that my card doesn't use Atmel at all. It's a "v2" card in which they silently switched chipsets while keeping the model number and packaging the same. Doh!
Worse, the "new" chipset is an AMD Alchemy Am1772, which has apparently no Linux drivers at all. So here I am, stuck in a hotel in Schipol, writing this using IE on Windows 2000 using my wireless card.
I'm intending to sell this laptop, but before I do I might try and hack out some drivers for this chipset - that's the only way this stuff will improve. I already wrote to AMD asking for the specs, we'll see what they say.
Though FWIW before giving up on the ghost-in-the-shell Atmel chipset I searched for info on using it with MacOS X - the only web page that talked about it (only 1, sad) was a hacked up version of the old SourceForge driver which has been obsoleted twice on Linux. So, the grass is no greener on that side of the fence.
I hope support for wireless cards increases soon. As ever one of the biggest things holding Linux back is compatability - how ironic that I'm on my way to WineConf and I'm using Win2K to talk about Linux. Hardware and software compatability, this is what it boils down to.
I haven't programmed directly in the Win32 API beyond making a few calls from VB (back when I was forced to use that steaming pile...), but the general gist is that it is comparable to Xlib
Well, not really. Xlib is more comparable to the GDI and a bit of USER - a very small part of Win32 in general. Yes, using it is a pain in the arse. That's why Borland make a killing selling the VCL/Delphi etc.
Qt, with its support applications (Qt Designer being the cream of the crop); its incredible documentation; and it's thoroughly well-designed API, was a dramatic step forward from GTK+/GTK--. It is, all by itself, a compelling reason to learn C++ if you don't already know it.
It's worth noting that GTKmm (it hasn't been called GTK-- for years) is significantly different to the old GTK--, and apparently much improved. People I know who've worked with both say it's pretty much a tossup between them at the moment, with GTKmm being more modern (in the c++ sense) but Qt having better commercial support and documentation. In terms of capabilities and API they are roughly equivalent assuming you don't get anal about StudlyCaps vs underline_style or whatever.
Slashdot Mirror
Cars aren't platforms - you can't compare the two. If an OS has no users, it has no apps and it will never get users - ie it is a dead OS. If a car has no drivers, it could still have 20,000 drivers tomorow, ie it's a "sleeping" car ;)
OK, just make sure to use GTK# instead of S.W.F - gtk is a better toolkit anyway. Avoid the registry. Avoid Win32isms. Then it should be pretty portable.
There is no such DLL, window management is done in kernel and the code for it is spread between USER, GDI and NTOSKRNL, I think.
Um this is the correct behaviour in almost every circumstance. If you want to install the binary drivers you're supposed to drop to runlevel 3, this is even documented.
The alternative is that if the X server crashes, you get thrown to a blank text screen - I'd much rather be put back at the login screen. GDM is designed this way for good reasons, you know - in fact I think most display managers do this.
Unfortunately, nobody has yet come up with one.
It'd be really great to know what would encourage people to work on Wine, so we can help them. WineHQ is one of the friendliest communities that I've encountered, so I feel it has to be our processes or technologies (or maybe just the nature of the beast) that scare people off.
Of course, if the poster can show specific sections of code he feels have "fundamental flaws" and describe them satisfactorily then I'll take my words back.
The way binreloc works is by taking the address of an empty string symbol from the GOT then scanning linker maps in /proc/self/maps to find itself. This is 100% robust and works regardless of whether the code is used inside the executable or library. It also gives you an absolute path every time with no manipulation needed.
So the real question is, if it's so easy why doesn't glibc provide a function to do it for you?
On Windows, the linker records which DLL a symbol comes from and you can explicitly specify it in the source/header files using some simple language extensions. On Linux, that isn't done, and worse ELF specifies unscoped symbol fixup semantics.
To rephrase the original question: if libA1.so is linked against foo_func() in libA2.so, and libB1.so depends on foo_func() in libB2.so, and binary Z links against libA1 and libB1, then the results will not be what you expect. Both libA1 and libB1 will be linked to the foo_func() in libA1, because that came first in the load order.
This causes problems when different parts of the program use different versions of the same library - they may be independent parts of the code but the wires get crossed inside ld.so and things go boom.
It'll need to be fixed at some point. Using the ELF grouping extension in Solaris seems to make sense. Somebody just needs to write the code and (this is the hard part) get it accepted upstream.
So? Managed code is not the only way to eliminate buffer overflows. Go read up on exec-shield and PIE binaries to see another way that's being deployed on Linux right now.
It's not so much the location of the overflowed buffer that's the problem, it's the location of the GOT (or IAT on Win32) that matters, as that allows you to call any function imported by that binary. On Windows PE binaries usually have their relocation records stripped so they always load at 0x400000, making the IAT easy to access by an absolute jump. On Linux the situation is mostly the same, albiet with a different address, unless you are using Fedora Core 1 in which case exec-shield with PIE binaries are used to give binaries randomized load addresses. One of the reasons it's called exec-shield is because it helps reduce the problems of buffer overflows - at least it makes it harder to run useful code (you can still crash the app of course).
Well, Microsoft always claim that the reason it takes them so long to get security fixes out is because they have to QA it, make sure they don't break apps etc - but I really don't understand this. It's a buffer overrun. Change the code to calculate the size then use dynamically allocated memory and it's fixed, right? Worst case, put bounds checking in there. How on earth could this possibly even affect public API? How could this cause regressions in apps? If there are apps out there that break because of security fixes like this, why should we care? Isn't the security of millions more important than those crack-ridden apps?
Nah. It's easy. Just stick it into a .tar file, call it "runme", mark it +x (tar preserves permissions). All modern desktops include a visual archive viewer like File Roller or ark, which allow you to open/run files direct from it. I don't know if you can run an ELF binary direct from file-roller, but I expect it's not too hard. Certainly most users, once tricked into wanting to run the file, could do it, especially as Linux desktops get more straightforward.
This prevents certain users from writing their own programs and scripts, but hopefully one would feel comfortable granting an exception for these more advanced users and giving them some space for programming.
noexec provides no security at all, any script or ELF binary can be run by using the appropriate interpreter. For most ELF binaries the interpreter is /lib/ld-linux.so.2, and it takes as an argument the binary to run.
Whoa, slow down. That's not right at all. Firstly, some RPMs are compatible across distributions, but not all - and it's basically hit and miss.
The linker fixup problems are one issue yes, but to be honest these occur rarely, especially once you start stripping unnecessary DT_NEEDED entries from your binary (unnecessary -lfoo options).
Eventually we'll need to change it to be more like how Windows does it, but it's not a high priority. Fixing build tools to not dump piles of bogus (in the case of recent toolchains) -lfoo options on the compiler is a more important issue, but I have no idea how to fix this in a general way. Possibly extensions to pkg-config would need to be made, certainly this is something that will require large-scale changes to peoples build systems.
I'm hoping that when autopackage is released and stable, it'll be so fantastically popular that it will motivate people to fix these myriad binary portability issues in their apps (and none of them are unsolvable or inherent in the way Linux works). We're writing a guidebook to help people do this, but it's not really released yet.
Nope, they can do it because they have a standardised platform. All MacOS X apps have at least one implicit dependency - on some version of MacOS. That one dependency is very easy (well, assuming you are rich) to satisfy, but it gives you a whole pile of functionality.
Because desktop Linux is evolving at such a rapid rate, and because nobody controls it, and because people like being able to control what's on their system to a fine degree, we have no such platform currently.
Unfortunately the first attempts at such a platform foundered when KDE made the bum choice of using a toolkit with a problematic license, so Gnome was started in reaction and now we have two, with neither being widely spread. The Gnome guys are busy moving infrastructure out into non-Gnome libraries like GTK, Cairo, DBUS etc that are explicitly designed to be acceptable to everybody, but unfortunately the KDE guys are still having big internal arguments about whether freedesktop.org (the new attempt) is "forcing" things upon them (see the discussions at kdedevelopers.org)
This is unfortunate because a standard platform that you could depend upon with only one dependency would go a long way towards making software on Linux easier to install.
I think once you spent hours disassembling and debugging these "simple" installer programs to make them run on Wine you'd have a different view on the matter ;)
Let's do a quick review of how things are done on Windows:
This is sort of how autopackage works, except we do it in a much simpler way and don't rely on CORBA (the nearest equivalent of DCOM on Linux). These installers have no dependency management beyond "is this file the right version? No? replace it then" which has caused some truly horrific hacks like Windows File Protection.
Yes, Windows apps have dependencies too. Check out this list to see..
MSIs "deal" with dependencies by including the least common ones inside themselves, causing huge and bloated downloads, and leaving the user to figure out random breakage for ones that don't exist (how many times have you found that an app assumes the presence of some VB/VC++ runtime lib that just wasn't there?).
They can get away with this because Windows is a platform and a whole pile of technology is guaranteed to be present. For instance, you know without needing to check that graphics support is available, because it's a part of the kernel and cannot be removed. On the server that's an achilles heel, on the client it's an advantage (in terms of packaging).
Because there is no standard Linux platform (the LSB never caught on), and the user can basically arbitrarily add, remove or upgrade individual components as they see fit (from the kernel to the theme in use) package managers are used to manage and maintain it all. Unfortunately, because there is no standard platform, the distro becomes the platform - of which there are many.
The freedesktop.org platform effort and the LSB are both worthy steps forward in this area and I hope they pick up steam. In the meantime, approaches like autopackage, being dependency-smart and having communities of packagers are the way forward.
For now, if it doesn't work, use autopackage.sunsite.dk and bear with us as we fixup the broken links etc.
DRM is not about strong encryption. DRM is about stopping you saving files to disk, sending them to friends, burning them to CDs. It's effectively about preventing you from moving data around like you can do normally.
I can't think of a good way to do open source DRM. You can put as much encryption as you like in, you could even do a Windows XP and encrypt audio right into kernelspace, but at the end of the day it's all just a few patches away from being intercepted easily. And once it's been intercepted, you can strip the DRM and move stuff around easily again.
Yeah. This is a tricky one. I'm not sure how it'll play out. Most likely if Linux has taken off by the time DRM gets big we'll just end up with binary, proprietary kernel modules and apps to do it. End of story.
At least this is the theory. I have no idea if SELinux actually is that fine grained, but I expect it could be made so if not. You could then assign sandboxed permissions to an installer.
One issue is that in autopackage each installer/.package file is actually what runs the installation process, there is no supervisor process like in RPM, so you'd have to remember to use one explicitly. While we could of course make a .package file surrender itself to such a supervisor process, that wouldn't be reliable as the code to do it could always be hacked out by the malevolent packager. An interesting problem for sure.
BTW I read and inwardly digested your other comments too. I'm still pondering them... it's certainly not a black and white issue.
Gnome 2.6 will feature a new file selector throughout, though individual GTK apps still must be ported to use it.
That's right. When you have piles of packages (source or binary) hosted on single servers run by the same group of people, you're making yourself a really tempting target. You don't even have to trojan a package - just find an exploit then DDOS the update servers so people can't access the fixed packages easily and you've bought yourself some time. As for large repositories of unsigned packages - let's not even go there.
There is no 'certificate' which can be attached to them to guarantee their purity. What the Linux community needs, I feel, is a type of central signing authority or cryptographically sealed DRM-compatible package management system.
No, the last thing Linux package management needs is more centralization. What we need is *less* centralization.
How many times have you heard of Windows users being compromised by trojaned InstallShield Wizards? I'm not talking about binaries a virus has infected, I mean bent installers. I've never heard of such a thing. Even if it has happened (and I expect it has a few times), it's a very hard way to infect somebodies system because you have to compromise a server, rebuild the installer somehow and then you only manage to get one package which may or may not be run by lots of people anytime soon.
What Linux package management needs to be more secure is for projects to host their own binary packages as they do for source packages. That way if/when breakins occur, the damage is at least limited.
And it would be impossible to accidently load and install a trojan.
I think this is wrong- if upstream is trojaned you are still screwed. Packagers don't audit the code, you know.
To be more specific, the kernel passes control via .interp to the rtld, which performs dynamic linkage (printing stuff out) but it never passes control to the entry point. So the original posters assertion that you need a separate test executable for ldd is entirely wrong, and shows only that he's never actually used the tool in question.
If you want an approach that works by reading the ELF binary directly try:
objdump -x foo | grep NEEDED
which will show direct links only, rather than ldd which shows every DSO mapped into the process image.
You've got to be joking. You think Mach-O is superior to ELF or PE? No way joe, no way in hell.
Let's take a quick review of some of the more stupid parts of the MacOS X shared library/exec format systems:
No thanks. ELF is an extremely efficient and well designed format, with the only major wart remaining being the lack of a GNU implementation of grouped fixup - hardly a fault of ELF itself, thinking about it.
It's pretty much a superior setup to the average linux world. But then, we paid for something besides just iCandy, right?
That's pretty much classic product psychology. "I paid more for it, and my judgement is sound, so therefore it must be better".
In fact the reason MacOS X uses Mach-O is because it uses the Mach kernel, which it uses not through any technological superiority (in fact the going opinion these days is that mach is trash), but because they hired Avi Tanenbaum (sp?).
Guess what? It turns out, after a quick email exchange with the authors of those drivers, that my card doesn't use Atmel at all. It's a "v2" card in which they silently switched chipsets while keeping the model number and packaging the same. Doh!
Worse, the "new" chipset is an AMD Alchemy Am1772, which has apparently no Linux drivers at all. So here I am, stuck in a hotel in Schipol, writing this using IE on Windows 2000 using my wireless card.
I'm intending to sell this laptop, but before I do I might try and hack out some drivers for this chipset - that's the only way this stuff will improve. I already wrote to AMD asking for the specs, we'll see what they say.
Though FWIW before giving up on the ghost-in-the-shell Atmel chipset I searched for info on using it with MacOS X - the only web page that talked about it (only 1, sad) was a hacked up version of the old SourceForge driver which has been obsoleted twice on Linux. So, the grass is no greener on that side of the fence.
I hope support for wireless cards increases soon. As ever one of the biggest things holding Linux back is compatability - how ironic that I'm on my way to WineConf and I'm using Win2K to talk about Linux. Hardware and software compatability, this is what it boils down to.
Well, not really. Xlib is more comparable to the GDI and a bit of USER - a very small part of Win32 in general. Yes, using it is a pain in the arse. That's why Borland make a killing selling the VCL/Delphi etc.
Qt, with its support applications (Qt Designer being the cream of the crop); its incredible documentation; and it's thoroughly well-designed API, was a dramatic step forward from GTK+/GTK--. It is, all by itself, a compelling reason to learn C++ if you don't already know it.
It's worth noting that GTKmm (it hasn't been called GTK-- for years) is significantly different to the old GTK--, and apparently much improved. People I know who've worked with both say it's pretty much a tossup between them at the moment, with GTKmm being more modern (in the c++ sense) but Qt having better commercial support and documentation. In terms of capabilities and API they are roughly equivalent assuming you don't get anal about StudlyCaps vs underline_style or whatever.
What if you are your own employer?