Apple users understand that time pretty much equals money and would rather pay to take the hassle out of life and get on with the rest of theirs.
What a load of toss. Linux users don't have a "moral objection" to paying for things, far from it. Apple users are known for paying for goods with ridiculously high margins because they've convinced themselves that their kit is "higher quality" than what the proles use. Or something. Nobody uses Macs at work anyway so they don't get the opportunity to warez stuff.
I mean come on. It's pretty simple - Macs are only bought by an affluent section of the market that places a great deal of importance on "lifestyle tech". This is simple market dynamics - stupid stereotypes of what non-Mac users think or do just shows you to be a fully paid up drone.
You make it sound like Apple is just bursting with posies in its niceness. I've yet to meet any credible people who believe that given half the chance Apple wouldn't have turned out just like Microsoft, or even worse. You only have to look at their history of using lawyers as weapons to suddenly start appreciating the lack of lawsuit-happiness over at Redmond.
The simple fact of the matter is that most Slashdot posters wouldn't know consistancy of opinion if it slapped them round the face with a wet kipper. It's fashionable to like Apple, it's fashionable to dislike Microsoft. The fact that they are just two sides of the same coin is something most would apparently rather ignore.
ASIO isn't needed on Linux. CreamWare drivers are apparently being written by CreamWare themselves and VST plugin integration via Wine was working months ago (though I dunno about integration with the tools).
VST instruments I'm not sure about, but I wouldn't be surprised if you could do the same trick as for VST plugins.
Too bad there are no specs for the CreamWare cards, but I guess binary only drivers are better than none. Open hardware is clearly going to be another days battle.
Ah but the people who won't understand this, are the same people who don't understand why the lack of CMYK support is such a limiting factor for Gimp.
Ah, but it's not. How many people do you know that have done image manipulation at some point in their lives with a computer? Lots, I'd expect. I know I do. How many of them need support for professional printing equipment? None.
You'd be totally amazed at the number of people out there who write music using their PC, keyboard, sample editor and guitar. I know several. For people like that, who actually care about not warezing VST or SoundForge, this sort of stuff is a dream come true.
Of course, I am sceptical that anybody but those who do music professionally actually pay for that stuff, but hey. Here at work we all use the Gimp.
Non-priv'd users are a big part of why Linux viruses are NOT a big
Oh, I don't think so. Your typical email virus doesn't need root privs, and if it wants to email random documents it can do that pretty easily. There's nothing wrong with having a root/user separation but unfortunately the balance is all wrong. Why do I need to be root to use "beep" (well actually it's setuid on most boxes). There are a whole load of things that root is needed for when actually for a desktop box, it just gets in the way.
Interesting views. Good interview.
Yes, I was impressed as well. Good on Mr Robertson, he gets an astonishing amount of dirt thrown at him around here, maybe that will change in future.
Ok, I can see the root/non-root issue is going to be discussed to death. Anyway, I just thought I'd point out that Robertson seems to see Wine only as a way to run MS Office, when in reality it seems to be used far more for other, non-Microsoft apps. Although it's better to have free software (note, not the same as native), there's so much stuff out there that isn't practical on a day to day basis yet. Wine is a useful answer to that. I hope on day he returns to the fray.
"Out of the box", it's unusable. I don't know what they were thinking with the default Sawfish configuration or the arrangement of the Mac-like menu bar across the top and the tasks list on the bottom.
Uh, what? Look, I know that you're trying to ramp up lots of karma in order to troll later, it says so in your user profile, but if you're going to do it, do it properly. GNOME2 doesn't use sawfish by default, and the top bar is not "Mac like" - that would imply that application menu bars get put there. It's little more than a standard panel with a couple of menu items on it.
I'm having an especially hard time figuring out how the default Redhat 9 layout is more usable, save for perhaps being more similar to Windows. I'd note that the stated reason for using this layout was because they wanted KDE and GNOME to look the same, and KDE couldn't replicate the default GNOME layout - it had nothing to do with increasing usability, and everything to do with reducing documentation costs and increasing standardisation.
In particular, I can't understand how a little red hat is more obvious than a menu with "Applications" and "Actions" on it unless you are very used to Windows and expect a start button clone. That may well be the case, but it says more about market conditions than usability.
Well, it's not really solid yet, but netRhythmBox is supposed to be able to deal with large quantities of music. It's pretty similar to iTunes in terms of GUI, although that's more because the huge UI flamewars/discussions failed to produce a consensus than because they like that actual layout.
Anyway. I can use it now without it crashing all the time. It's based on GStreamer (which kicks ass), is a GNOME2 app and can do Internet Radio (cd audio is coming up apparently). It has music library organisational style features.
So, has a lot of potential, once it gets more mature.
DirectFB apps, that use the DirectFB API, are not network transparent, and probably never will be. DFBTerm for instance.
The fact that most apps are capable of using the X protocol today, and that DirectFB implements a small X server, does not mean that apps which talk to DirectFB itself are network transparent.
So here's the stupid question: why didn't (or hasn't) someone build a graphical syb-system that's modular?
Well, X is actually modular. It doesn't use the network subsystem when run locally.
Why can't you have a well-written, clean API (I've heard horror stories from people who've had to write code directly to X)
I've just been doing some Xlib programming (for wine). It's not that bad. Win32 is certainly a LOT harder and less intuitive. But very few people use Xlib directly anyway.
that lets you plugin in modules like 'network-transparency' or 'anti-alisased fonts', or even everyone's favourite 'alpha-blended windows'?
Yes, X provides exactly that, with the exception of alpha blended windows, but that's because more hacking is needed inside the XFree drivers architecture to make it work at acceptable speeds.
The original post (which was itself quite amusing) is now at -1 Funny, so you won't see it, nor get the parent post.
Rather worryingly, it's at -1 Funny and yet no "Overrated" mods are shown in the box below - considering that overrated moderations are no longer shown and are not meta-moderated, this seems like a wide open hole for people who want to abuse the moderation system. What is the reason for this inconsistancy? Why is overrated/underrated special?
That's what they're developing Fusion for - to allow multiple windows to interoperate on the same desktop. It doesn't have to be used for this, but AFAIK that's a long term goal of the project.
Fellow Americans! I have a message for you, that you should all heed. It should be noted that thanks to the evils of the DCMA and M$ Palladium, using the kernel to display graphics poses a grave threat to our freedoms, which were so vigourously defended by our brave soldiers in Iraq (unless you are one of those cheese eating surrender monkeys, the french *spits*).
You see, this is not a new nor innvoative technique! M$ also has some graphics in kernel - this is what allows them to pander to the MPAA/RIAA when they demand unbreakable DRM. They is almost certainly patented as a result! Do you want to be sued for playing MP3s with DeCSS on Linux? NO! There is only one choice - just say no to having your multimedia use the kernel... just say no to DRM!
DirectFB puts our freedoms at risk my fellow Americans, because the government assumes that all P2P users are terrorists, as opposed to freedom loving consumerists who merely wish to try before they buy. Everybody knows that piracy isn't theft - how could it be, when most pirates wouldn't have even bought a copy anyway?
So you see, if people use DirectFB you don't only lose network transparency (who uses that anyway?) - you lose something far more important - your FREEDOM. With X, at least you can swap out XFree for another server, becuase being BSD licensed means it is truly Free, unlike that pinko commie Linux kernel.
Karma: Was Excellent, Before I Posted This Karma: Was Excellent, Before I Posted This
It's a thin layer on top of the kernel framebuffer driver - provides useful APIs and some other services that you need for a windowing system, like WM support. They were also working on a fast IPC mechanism called Fusion when I last checked up on them. Dunno how far that's got.
The idea is to replace X with something closer to the hardware as far as I know, but today it's mainly useful in embedded scenarios. They have a backwards compatability thing for X clients, which means if you have a supported card you can run your desktop on it and make windows transparent with the capslock key. It's fun for about 2 minutes I should imagine.
As an aside, does anybody know if the girl in that screenshot lives is single?:D
I was wondering when this one would show up on Slashdot. A few thoughts:
1) Today, DirectFB can do some things XFree cannot, but the reverse is also true. But, the XFree infrastructure could be (and will be) upgraded to do stuff like full use of hardware accelerations, proper save unders, alpha blended windows and so on. DirectFB cannot gain network transparency or code portability however.
2) On the other hand, using DirectFB does not mean we lose network transparency. The X11 protocol won't disappear. If it had better hardware support, or was able to use the XFree drivers, I'd have no problem at all using this software. For apps that used GTK/Qt I'd always have the choice of network transparency when I needed it. Software written for DirectFB specifically probably isn't the sort of thing you'd want to run remotely anyway.
3) Window transparency is overrated. Window double buffering is not.
4) DirectFB still has a lot of questions to answer. AFAIK there is still not window management protocol for instance - X11 provides a lot of things most people don't think about, DirectFB would have to provide equivalents first.
5) Half the comments in this thread about XFree will be misinformed;)
an open (fully documented and non-proprietary) form
I see a lot of people saying this on Slashdot. Unfortunately, it's rather badly defined exactly what "non-proprietary" is, and I feel that open formats are only half the story anyway. By now the MS Office file formats have been mostly reverse engineered and there is documentation available on the web about them. OpenOffice can read them, as can AbiWord. AbiWord however, cannot read OpenOffice files (d'oh).
So, which is more open? They are both fully documented, arguably Word has better multi-vendor support. Both the OpenOffice and Word formats are controlled by large companies (effectively). Therefore, by your logic, we should all use Word. Except that Word isn't open source nor free software, and we've got nowhere.
Open formats are one thing, but they are useless without equally open implementations as well. Hence the emphasis on the software.
No no, read the testimony. This isn't about forcing people to use open source, it's about forcing people to consider it. Everybody knows there are some things open source can't do, some things that proprietary software does better, somet things free software does better BUT there's too much lockin to make it worthwhile etc etc etc.
This is just about trying to counter balance the lobbyists (why do such people even exist?).
Use whatever is going to be the most suitable. It's as easy as that.
The sticking point is how to define what is most suitable, and to ensure that all options are considered (often they are not).
Shrugging it off with "it's as easy as that" is rather naive - it assumes civil servants are perfectly informed and completely neutral, something that unfortunately is not the case in the real world.
Yes this is a problem. In our own example we would like people to be able to write programs of their own that use our shared library, but our shared library will not work unless it can find it's other support files.
Sounds like you could use libprefix. If you want to help (it's only simple) drop by #autopackage on freenode.
more imporantly "de-installation" is "rm -r thedirectory".
That works for simple apps, but most installs alter things out of prefix, adding.desktop files for menus, icons, CORBA registrations etc etc.
I think the flaws area addressed by changing how directories are read/written so that most programs can treat these AppFolders as plain files.
The flaws mostly revolve around the fact that you cannot treat Linux software atomically, due to dependancies. There are others.....
Firstly, MSI is not implemented because nobody cares enough about it to implement it. If someone needs it, they will implement it. Sure, Microsoft has tons of resources, but they can't push APIs on developers faster than the latter can learn them.
Sure, APIs we can install into Wine (like MSI) are OK for the sort term, but require you to have a Windows license. That was only one example. DCOM perhaps is a better one. Sure sure, you can write off everything with a 'thats not implemented because nobody cares' attitude, but to a large extent that isn't true. We want a full DCOM implementation, but don't have the resources.
Also, GTK doesn't have a brain damaged design? Where did you get that one from?
Uh, consistant APIs, containment based layout, signals/slots based callbacks, easy bound to other languages, clean graphics abstraction, plugin image loaders.... GTK has *loads* of good features and smart design. You've fallen into the trap of 'oh, its in C, it must be stupid', which is IMHO stupid itself. Object Orientation is a function of design, not the language. There are valid reasons for using C, namely that it makes it easier to reuse from other languages.
Win32, I'd note, is also written in C, but is not OOP, and is a PITA to bind to other langauges. Which is more stupid? By your own logic, Win32 is brain damaged beyond repair. At least GTK is OOP, and if you use gtkmm, you never need touch raw C if you don't want to.
Also, I know several programmers, and most of them find Win32 quite well-designed.
How many of them have used other toolkits extensively though? Why do virtually all Windows programmers use wrappers (vcl, mfc, visual basic,.net) if Win32 itself is so well designed?
Win32 has bad design leaking out of its ears, not to mention massive amounts of inconsistancy.
Furthermore, the tools that are available for open-source development with GTK are scant. When someone makes something that's as good as Visual Studio, then we'll talk. Developing with just a text editor is very 1980s.
Yet strangely I'm just as productive with GTK/Emacs as I am with Delphi. Developing without an IDE on Windows isn't an option, because Win32 is so piss poor. Without advanced wrappers and code generators, you're basically shafted. In contrast, it's actually possible and easy to program things directly with GTK/Linux (or Qt). Don't be misled by the text editor description of emacs, it has code completion, interactive help and of course blows any standard Windows text editor out of the water. Everybody uses Glade with xml these days anyway, so you don't need the GUI editor integrated with the code editor in order to get generated code etc.
Microsoft APIs are actually quite stable, and it is not a difficult task to keep up with them once all the major subsystems are fully implemented. Furthermore, there is about a one-year delay between the publication of an API spec and the publication of the first games that use it.
You're ignoring the fact that Microsoft have far more resources than we do. MSI was implemented years ago, but nobody has even started a Wine implementation.
Finally, I don't see how support for Win32 APIs is a bad thing. They are good APIs, much better than many Linux equivalents.
Blargh! Like what? Win32 is a nightmare. Win32 controls may have more features than their GTK equivalents, but GTK doesn't have a brain damaged design.
But yeah, we need them for compatability unfortunately.
We need to be able to stuff a directory tree into a single file and have the OS mount it automatically - similar to the loopback but with the following difference.
Yeah, this would be cool but mostly for the area of usability rather than security. Being able to right click a directory and choose "Convert to box", and have the directory turn into a file would be useful for many reasons - you can't easily put a directory in a manageable form on the net nor in emails. Think how often zips are used just to glob files together.
Done transparently, this'd be a real usability win. Dragging a directory onto an email becomse possible, because it's automatically boxed. You don't have to separate the concept of "archive" from "contents" - if you have a box, unbox it and it turns into a directory. Rebox it, and it goes back to a file. Ditto for dragging onto friends in Gaim.
0. Everybody should know that you can find where the executable is in/proc/self/exe.
For autopackage we have a "libprefix" library you can use to find out your installation prefix, but we need people to work on it. You up for it?
The problem with/proc/self/exe is that it only works for binaries, not libraries which also sometimes need to be deprefixed. You can scan the maps list for it, but things get messy rapidly. We're probably going to extend our current database-backed system with these techniques, but we need somebody to write the code.
2. Programs should use the application directory to look for their configuration files. (They should also look in ~/.appname and maybe/etc, but no files are required there).
What is the application directory? What's wrong with/etc and ~/.appname? Some apps look in $prefix/etc as well (usuall configurable at compile time).
3. The shells or exec() or something should be fixed so if you have a directory called appname with an executable file in it called appname/main, then typing the name of the directory, or finding it on the PATH, will in fact execute appname/main. Note: no stupid ".app" extension that OS/X uses.
That probably wouldn't be useful. AppFolders could be implemented on Linux with the changes you describe, but I've yet to be convinced that they don't suffer fundamental design flaws.
4. Most serious change is to read/write. A program is allowed to read a directory and to write an empty directory. The resulting data is exaclty as though tar was run on that directory. This will allow utilities that don't know about directories to copy these applications and also to email them and so on.
This is one of the changes Reiser5/Reiser6 will introduce (but far more flexibly).
Drag 'n drop installation! Think of the possibilities!
Blah. Doing that well is really hard. Dependancies are the main problem. No, the approach MacOS or ROX take is not acceptable, Linux is not monolithic like MacOS, and in fact Thomas Leonard who writes ROX has been playing around with filing system extensions and stuff lately so you can avoid installing apps altogether. Pretty radical.
We did some research/experiments to see what it'd take to give an appfolders style GUI for autopackage. Conclusion was that it could be done by having good integration with KDE/GNOME, but it wouldn't look like NeXT appfolders - rather, you could have icons embedded into web pages. Dragging the icon onto your panel drops it in, it goes grey and a little spinner emblem appears over it, so you can monitor the progress of the download. When done, the installation proceeds headless, resolving any dependancies it may have. Clicking the icon while grey pops up a window showing progress. Eventually when the install is complete, the icon fades into colour, the emblem turns into a little tick mark and maybe there's some other form of notification. When done, clicking the icon launches it.
So, what can you do with this launcher icon thingy? Well, we want to stay consistant, so clearly you can drag and drop it around. What that does is just send a link really, dropping the package into an email, or onto disk, or onto a budddy in Gaim doesn't send the actual package - that is not useful as the target machine may be a different architecture, may require different optimizations, may need different file installations and might have unresolved dependancies, instead you send the.desktop file which contains all the information you need to install the program at the other end. That's something that appfolders don't do well (but on the mac it doesn't matter, only 1 arch, no dependancies, fat binaries are a big hack but most mac users aren't going to be stuck on modems anyway)
Right clicking the launcher gives you options like "upgrade", "remove this application", " show information" and so on.
Multiple users are another fun thing that AppFolders finds hard to do well. If user A installs the app, user B may wish to use it as well. If A then decides they don't like it, you want them to be able to "remove" it while still keeping it installed for B. So, one idea is that desktop launchers are reference counted.
Anyway, there are lots of things we can do much better than drag and drop folders, once we get the right technology in place and start using workable abstractions.
Linux is going to end up with the coolest software management system ever, believe me. Ignoring my personal involvement in it completely, other people are working on this too, and the groundwork is being laid for this being a feature rather than a problem within the space of a few years:)
Slashdot Mirror
What a load of toss. Linux users don't have a "moral objection" to paying for things, far from it. Apple users are known for paying for goods with ridiculously high margins because they've convinced themselves that their kit is "higher quality" than what the proles use. Or something. Nobody uses Macs at work anyway so they don't get the opportunity to warez stuff.
I mean come on. It's pretty simple - Macs are only bought by an affluent section of the market that places a great deal of importance on "lifestyle tech". This is simple market dynamics - stupid stereotypes of what non-Mac users think or do just shows you to be a fully paid up drone.
The simple fact of the matter is that most Slashdot posters wouldn't know consistancy of opinion if it slapped them round the face with a wet kipper. It's fashionable to like Apple, it's fashionable to dislike Microsoft. The fact that they are just two sides of the same coin is something most would apparently rather ignore.
VST instruments I'm not sure about, but I wouldn't be surprised if you could do the same trick as for VST plugins.
Too bad there are no specs for the CreamWare cards, but I guess binary only drivers are better than none. Open hardware is clearly going to be another days battle.
Ah, but it's not. How many people do you know that have done image manipulation at some point in their lives with a computer? Lots, I'd expect. I know I do. How many of them need support for professional printing equipment? None.
You'd be totally amazed at the number of people out there who write music using their PC, keyboard, sample editor and guitar. I know several. For people like that, who actually care about not warezing VST or SoundForge, this sort of stuff is a dream come true.
Of course, I am sceptical that anybody but those who do music professionally actually pay for that stuff, but hey. Here at work we all use the Gimp.
Oh, I don't think so. Your typical email virus doesn't need root privs, and if it wants to email random documents it can do that pretty easily. There's nothing wrong with having a root/user separation but unfortunately the balance is all wrong. Why do I need to be root to use "beep" (well actually it's setuid on most boxes). There are a whole load of things that root is needed for when actually for a desktop box, it just gets in the way.
Interesting views. Good interview.
Yes, I was impressed as well. Good on Mr Robertson, he gets an astonishing amount of dirt thrown at him around here, maybe that will change in future.
Ok, I can see the root/non-root issue is going to be discussed to death. Anyway, I just thought I'd point out that Robertson seems to see Wine only as a way to run MS Office, when in reality it seems to be used far more for other, non-Microsoft apps. Although it's better to have free software (note, not the same as native), there's so much stuff out there that isn't practical on a day to day basis yet. Wine is a useful answer to that. I hope on day he returns to the fray.
Uh, what? Look, I know that you're trying to ramp up lots of karma in order to troll later, it says so in your user profile, but if you're going to do it, do it properly. GNOME2 doesn't use sawfish by default, and the top bar is not "Mac like" - that would imply that application menu bars get put there. It's little more than a standard panel with a couple of menu items on it.
I'm having an especially hard time figuring out how the default Redhat 9 layout is more usable, save for perhaps being more similar to Windows. I'd note that the stated reason for using this layout was because they wanted KDE and GNOME to look the same, and KDE couldn't replicate the default GNOME layout - it had nothing to do with increasing usability, and everything to do with reducing documentation costs and increasing standardisation.
In particular, I can't understand how a little red hat is more obvious than a menu with "Applications" and "Actions" on it unless you are very used to Windows and expect a start button clone. That may well be the case, but it says more about market conditions than usability.
Anyway. I can use it now without it crashing all the time. It's based on GStreamer (which kicks ass), is a GNOME2 app and can do Internet Radio (cd audio is coming up apparently). It has music library organisational style features.
So, has a lot of potential, once it gets more mature.
DirectFB apps, that use the DirectFB API, are not network transparent, and probably never will be. DFBTerm for instance.
The fact that most apps are capable of using the X protocol today, and that DirectFB implements a small X server, does not mean that apps which talk to DirectFB itself are network transparent.
Well, X is actually modular. It doesn't use the network subsystem when run locally.
Why can't you have a well-written, clean API (I've heard horror stories from people who've had to write code directly to X)
I've just been doing some Xlib programming (for wine). It's not that bad. Win32 is certainly a LOT harder and less intuitive. But very few people use Xlib directly anyway.
that lets you plugin in modules like 'network-transparency' or 'anti-alisased fonts', or even everyone's favourite 'alpha-blended windows'?
Yes, X provides exactly that, with the exception of alpha blended windows, but that's because more hacking is needed inside the XFree drivers architecture to make it work at acceptable speeds.
Rather worryingly, it's at -1 Funny and yet no "Overrated" mods are shown in the box below - considering that overrated moderations are no longer shown and are not meta-moderated, this seems like a wide open hole for people who want to abuse the moderation system. What is the reason for this inconsistancy? Why is overrated/underrated special?
That's what they're developing Fusion for - to allow multiple windows to interoperate on the same desktop. It doesn't have to be used for this, but AFAIK that's a long term goal of the project.
You see, this is not a new nor innvoative technique! M$ also has some graphics in kernel - this is what allows them to pander to the MPAA/RIAA when they demand unbreakable DRM. They is almost certainly patented as a result! Do you want to be sued for playing MP3s with DeCSS on Linux? NO! There is only one choice - just say no to having your multimedia use the kernel... just say no to DRM!
DirectFB puts our freedoms at risk my fellow Americans, because the government assumes that all P2P users are terrorists, as opposed to freedom loving consumerists who merely wish to try before they buy. Everybody knows that piracy isn't theft - how could it be, when most pirates wouldn't have even bought a copy anyway?
So you see, if people use DirectFB you don't only lose network transparency (who uses that anyway?) - you lose something far more important - your FREEDOM. With X, at least you can swap out XFree for another server, becuase being BSD licensed means it is truly Free, unlike that pinko commie Linux kernel.
Karma: Was Excellent, Before I Posted This
Karma: Was Excellent, Before I Posted This
The idea is to replace X with something closer to the hardware as far as I know, but today it's mainly useful in embedded scenarios. They have a backwards compatability thing for X clients, which means if you have a supported card you can run your desktop on it and make windows transparent with the capslock key. It's fun for about 2 minutes I should imagine.
As an aside, does anybody know if the girl in that screenshot lives is single? :D
1) Today, DirectFB can do some things XFree cannot, but the reverse is also true. But, the XFree infrastructure could be (and will be) upgraded to do stuff like full use of hardware accelerations, proper save unders, alpha blended windows and so on. DirectFB cannot gain network transparency or code portability however.
2) On the other hand, using DirectFB does not mean we lose network transparency. The X11 protocol won't disappear. If it had better hardware support, or was able to use the XFree drivers, I'd have no problem at all using this software. For apps that used GTK/Qt I'd always have the choice of network transparency when I needed it. Software written for DirectFB specifically probably isn't the sort of thing you'd want to run remotely anyway.
3) Window transparency is overrated. Window double buffering is not.
4) DirectFB still has a lot of questions to answer. AFAIK there is still not window management protocol for instance - X11 provides a lot of things most people don't think about, DirectFB would have to provide equivalents first.
5) Half the comments in this thread about XFree will be misinformed ;)
I see a lot of people saying this on Slashdot. Unfortunately, it's rather badly defined exactly what "non-proprietary" is, and I feel that open formats are only half the story anyway. By now the MS Office file formats have been mostly reverse engineered and there is documentation available on the web about them. OpenOffice can read them, as can AbiWord. AbiWord however, cannot read OpenOffice files (d'oh).
So, which is more open? They are both fully documented, arguably Word has better multi-vendor support. Both the OpenOffice and Word formats are controlled by large companies (effectively). Therefore, by your logic, we should all use Word. Except that Word isn't open source nor free software, and we've got nowhere.
Open formats are one thing, but they are useless without equally open implementations as well. Hence the emphasis on the software.
No no, read the testimony. This isn't about forcing people to use open source, it's about forcing people to consider it. Everybody knows there are some things open source can't do, some things that proprietary software does better, somet things free software does better BUT there's too much lockin to make it worthwhile etc etc etc.
This is just about trying to counter balance the lobbyists (why do such people even exist?).
The sticking point is how to define what is most suitable, and to ensure that all options are considered (often they are not).
Shrugging it off with "it's as easy as that" is rather naive - it assumes civil servants are perfectly informed and completely neutral, something that unfortunately is not the case in the real world.
They don't have control of MPEG4 either, and due to patents/licensing, I doubt they could fork it if they weren't happy with progress.
Sounds like you could use libprefix. If you want to help (it's only simple) drop by #autopackage on freenode.
more imporantly "de-installation" is "rm -r thedirectory".
That works for simple apps, but most installs alter things out of prefix, adding .desktop files for menus, icons, CORBA registrations etc etc.
I think the flaws area addressed by changing how directories are read/written so that most programs can treat these AppFolders as plain files.
The flaws mostly revolve around the fact that you cannot treat Linux software atomically, due to dependancies. There are others.....
Sure, APIs we can install into Wine (like MSI) are OK for the sort term, but require you to have a Windows license. That was only one example. DCOM perhaps is a better one. Sure sure, you can write off everything with a 'thats not implemented because nobody cares' attitude, but to a large extent that isn't true. We want a full DCOM implementation, but don't have the resources.
Also, GTK doesn't have a brain damaged design? Where did you get that one from?
Uh, consistant APIs, containment based layout, signals/slots based callbacks, easy bound to other languages, clean graphics abstraction, plugin image loaders.... GTK has *loads* of good features and smart design. You've fallen into the trap of 'oh, its in C, it must be stupid', which is IMHO stupid itself. Object Orientation is a function of design, not the language. There are valid reasons for using C, namely that it makes it easier to reuse from other languages.
Win32, I'd note, is also written in C, but is not OOP, and is a PITA to bind to other langauges. Which is more stupid? By your own logic, Win32 is brain damaged beyond repair. At least GTK is OOP, and if you use gtkmm, you never need touch raw C if you don't want to.
Also, I know several programmers, and most of them find Win32 quite well-designed.
How many of them have used other toolkits extensively though? Why do virtually all Windows programmers use wrappers (vcl, mfc, visual basic, .net) if Win32 itself is so well designed?
Win32 has bad design leaking out of its ears, not to mention massive amounts of inconsistancy.
Furthermore, the tools that are available for open-source development with GTK are scant. When someone makes something that's as good as Visual Studio, then we'll talk. Developing with just a text editor is very 1980s.
Yet strangely I'm just as productive with GTK/Emacs as I am with Delphi. Developing without an IDE on Windows isn't an option, because Win32 is so piss poor. Without advanced wrappers and code generators, you're basically shafted. In contrast, it's actually possible and easy to program things directly with GTK/Linux (or Qt). Don't be misled by the text editor description of emacs, it has code completion, interactive help and of course blows any standard Windows text editor out of the water. Everybody uses Glade with xml these days anyway, so you don't need the GUI editor integrated with the code editor in order to get generated code etc.
You're ignoring the fact that Microsoft have far more resources than we do. MSI was implemented years ago, but nobody has even started a Wine implementation.
Finally, I don't see how support for Win32 APIs is a bad thing. They are good APIs, much better than many Linux equivalents.
Blargh! Like what? Win32 is a nightmare. Win32 controls may have more features than their GTK equivalents, but GTK doesn't have a brain damaged design.
But yeah, we need them for compatability unfortunately.
Yeah, this would be cool but mostly for the area of usability rather than security. Being able to right click a directory and choose "Convert to box", and have the directory turn into a file would be useful for many reasons - you can't easily put a directory in a manageable form on the net nor in emails. Think how often zips are used just to glob files together.
Done transparently, this'd be a real usability win. Dragging a directory onto an email becomse possible, because it's automatically boxed. You don't have to separate the concept of "archive" from "contents" - if you have a box, unbox it and it turns into a directory. Rebox it, and it goes back to a file. Ditto for dragging onto friends in Gaim.
For autopackage we have a "libprefix" library you can use to find out your installation prefix, but we need people to work on it. You up for it?
The problem with /proc/self/exe is that it only works for binaries, not libraries which also sometimes need to be deprefixed. You can scan the maps list for it, but things get messy rapidly. We're probably going to extend our current database-backed system with these techniques, but we need somebody to write the code.
2. Programs should use the application directory to look for their configuration files. (They should also look in ~/.appname and maybe /etc, but no files are required there).
What is the application directory? What's wrong with /etc and ~/.appname? Some apps look in $prefix/etc as well (usuall configurable at compile time).
3. The shells or exec() or something should be fixed so if you have a directory called appname with an executable file in it called appname/main, then typing the name of the directory, or finding it on the PATH, will in fact execute appname/main. Note: no stupid ".app" extension that OS/X uses.
That probably wouldn't be useful. AppFolders could be implemented on Linux with the changes you describe, but I've yet to be convinced that they don't suffer fundamental design flaws.
4. Most serious change is to read/write. A program is allowed to read a directory and to write an empty directory. The resulting data is exaclty as though tar was run on that directory. This will allow utilities that don't know about directories to copy these applications and also to email them and so on.
This is one of the changes Reiser5/Reiser6 will introduce (but far more flexibly).
Blah. Doing that well is really hard. Dependancies are the main problem. No, the approach MacOS or ROX take is not acceptable, Linux is not monolithic like MacOS, and in fact Thomas Leonard who writes ROX has been playing around with filing system extensions and stuff lately so you can avoid installing apps altogether. Pretty radical.
We did some research/experiments to see what it'd take to give an appfolders style GUI for autopackage. Conclusion was that it could be done by having good integration with KDE/GNOME, but it wouldn't look like NeXT appfolders - rather, you could have icons embedded into web pages. Dragging the icon onto your panel drops it in, it goes grey and a little spinner emblem appears over it, so you can monitor the progress of the download. When done, the installation proceeds headless, resolving any dependancies it may have. Clicking the icon while grey pops up a window showing progress. Eventually when the install is complete, the icon fades into colour, the emblem turns into a little tick mark and maybe there's some other form of notification. When done, clicking the icon launches it.
So, what can you do with this launcher icon thingy? Well, we want to stay consistant, so clearly you can drag and drop it around. What that does is just send a link really, dropping the package into an email, or onto disk, or onto a budddy in Gaim doesn't send the actual package - that is not useful as the target machine may be a different architecture, may require different optimizations, may need different file installations and might have unresolved dependancies, instead you send the .desktop file which contains all the information you need to install the program at the other end. That's something that appfolders don't do well (but on the mac it doesn't matter, only 1 arch, no dependancies, fat binaries are a big hack but most mac users aren't going to be stuck on modems anyway)
Right clicking the launcher gives you options like "upgrade", "remove this application", " show information" and so on.
Multiple users are another fun thing that AppFolders finds hard to do well. If user A installs the app, user B may wish to use it as well. If A then decides they don't like it, you want them to be able to "remove" it while still keeping it installed for B. So, one idea is that desktop launchers are reference counted.
Anyway, there are lots of things we can do much better than drag and drop folders, once we get the right technology in place and start using workable abstractions.
Linux is going to end up with the coolest software management system ever, believe me. Ignoring my personal involvement in it completely, other people are working on this too, and the groundwork is being laid for this being a feature rather than a problem within the space of a few years :)