Yes, the technical problem is the Trident, the IE rendering engine, is closed source and mostly rubbish.
You can already "embed" XUL in IE of course, by having the user download the Gecko ActiveX control and effectively embed a renderer within a renderer, but that's a cheap hack and has severe performance implications.
To be frank, I'm 100% not convinced that Avalon is going to be as world changing as Miggy predicts. I think it's especially rash to be starting internal projects even if they are "thought only" to develop a competitor.
Miguel thinks Avalon will be great, because it will let you deploy applications via the web browser that use native widgets, and be nicely integrated with.NET and so on.
But... but... but... Microsoft did this years ago (minus.net). Or am I really the only one who remembers the version of Outlook implemented entirely using DHTML/HTA (which produces native widgets). I can't remember the codename, but the project was scrapped. The benefits of running Outlook inside IE just were not compelling enough to overcome the performance and other problems.
I'm not denying it'd be useful. The long term UI goals for my own packaging/installer project are that the user should be able to launch (and implicitly install) software simply by clicking on an icon embedded in a web page. As far as the user is concerned then the effects would be the same, so the real differences lie in how the developer sees things.
In the Avalon world view, the developer creates widgets on a canvas (AFAIK), ties them together with.NET code, and then.NET CAS allows you to launch it from a web browser without fear of it doing nasty things to your machine (which is a massive oversimplification, but oh well).
In fact, we can do this sort of thing today, with technologies that are either here or just around the corner. SELinux allows you to effectively sandbox native code to a fine degree, similar to.NET CAS except enforced at the kernel level and not by a VM. It's not just a set of kernel security checks - it's actually a security architecture with an exposed set of APIs which allow people to use MAC security features to a high level.
I don't know enough about.NET security to know how it compares, but SELinux policy is easily distributable in the form of text files and allows you use native code, which runs directly on the CPU without the overhead of a VM and huge set of managed APIs.
So, if you can download some native code and correctly sandbox it, you have the start of web app deployment. XAML appears to bear a superficial representation to Glade (note: NOT xul) but using a more customised and therefore human friendly schema.
I say Glade and not XUL because a Glade file is, in actuality, not an UI description at all. It's really a persisted GObject tree that libglade uses along with the GObject reflection APIs to reconstruct the GUI at runtime. I have read that XAML despite appearances is similar: it is a persisted.NET object graph.
So, I think if Miguel starts from "what user experiences does this technology allow" and work backwards, he'll find we already have the basics in production. Sure, they need to be improved and tied together, but they are there nonetheless.
Finally I think it's wrong to say that the reason desktop Linux didn't happen in 1994 was because people were "sleeping at the wheel". The fact of the matter was in 1994 Microsoft already had several thousand people working on Windows full time, whereas desktop Linux had.... none.
Really, I think a simpler explanation is just that MS had a monopoly pumping cash into their development teams, and Linux did not. Its falling behind was therefore completely inevitable until it gained enough momentum to move as fast as Microsoft do.
Losing the X connection results in Xlib terminating the app immediately, unless the app has trapped X errors and tries to do something with them, which almost nothing does because ctrl-alt-backspace is the wrong way to log out. If the WMs used are so confusing that it's not clear how to log out, use a better WM.
It's like saying hitting reset is a good way to log out, It's not.
With WiX, I get under the impression MS gets to see how does it feel like to handle an open source project and maybe find a way to prepare to get revenue out of it (don't see it happening yet with WiX but they can learn for later)
WiX didn't cost Microsoft anything anyway, it was written in the authors spare time according to the original announcement and blog entries.
.... where - wait for it - the INITCOMMONCONTROLSEX structure has only two members, the first of which is dwSize. So in actuality, it has only one member, which is a bitfield.
Now I ask you. Why is it better to use a structure that has to be allocated and initialized for passing a parameter than simply introducing a new function in the (unlikely) case that new parameters need to be added?
Here's another example. Anybody who can guess what the RpcUseProtSeqEpExA function does, have a cookie. It's actually short for "Remote Procedure Call Use Protocol Sequence with Endpoint, Extended ANSI version".
I've yet to encounter any C API with more bizarre quirks than Win32. Whether it's typedeffing int to INT, inserting random reserved (must be 0) arguments into the middle of functions, inventing yet another set of error codes (like ERROR_SUCCESS:) or just generally being buggy and sucking, Win32 is a textbook example of how not to design an API.
If you want to see a good C API, take a look at GTK+.
The main problem is of course that corporations know exactly what they need to do in order to cut their pollutant emissions, but it's more expensive to do it cleanly. The rule of first mover advantage is inverted - ie the first company to go the more expensive route and clean up is more likely to lose money over it, so there's no incentive to do so.
By legislating that all companies must conform to minimum standards, this problem is removed.
That's less effective these days of course as corporates are more mobile across national boundaries, and the legal system hasn't really caught up yet. However the principle is sound and more to the point has a lot of prior art which indicates it works.
Wow, those two posts of yours really changed my mind on the war. Up until now I really wasn't sure whether it was a good idea or not, but this is one of the most clear and insightful analyses I've seen - certainly moreso than in popular media (newspapers, tv, etc). thanks!
I purchased Microsoft software because it performed a task or service that I was willing to pay for. At no point was I tricked or forced to buy the stuff
That's what you think. In actuality you thought you were buying the ability to write letters and create spreadsheets, but you were actually buying the ability to write DOC and XLS files, which is a different matter entirely.
Let me ask you - was the task or service you were willing to pay for using a computer, or using Windows? The two are often commingled but are actually different.
Only on Slashdot, made up mostly of college students and unemployed, would it be considered a bad thing and a "lack of integrity" to sell things for one company and then go over and sell things for another.
Depends on the job, and how you sell things. If you're selling second hand cars and you move to another state to sell them for a better salary, most people would not consider you lacking in integrity.
What we have here is different - only somebody incredibly naive would think that this guy made the sale of SuSE without once trashing or mentioning the bad points of Windows: seeing as how they are the closest competition and all. In fact, I wouldn't be at all surprised if that was the main selling point: Linux is better than Windows because (a) (b) (c).
Now the guy is going to be telling people the exact opposite. In other words, at one or other of the jobs (most likely both) the guy will have been flat out lying.
To be frank, I don't give a toss that the guy is in sales. There's right and then there's wrong, and if you are are lying through your teeth to make a sale you're still a lier. If you are influencing huge, important decisions people make on the basis of things you don't believe yourself.... well, in my world view you have no integrity and your job position does not excuse that.
I'm not saying this guy has no integrity! I don't know what his sales technique is like. It's possible all he did was point out how great SuSE Linux is, and how it'd meet their needs better and didn't mention Microsoft once. It's possible, but unlikely.
In other words, ad hominem attacks lack honour and integrity - and by the way bonch, that holds true whether you're attacking products, people or places.
The Glade XML format is kind of strange (it looks like XML described in XML; a pointless scheme)
It's a persisted GObject tree. libglade reads the XML which maps pretty much directly to constructing a tree of GObjects and setting their properties and signals. The reason it looks like XML describing XML is because it's describing a tree of attributed nodes, but with callbacks - ie they *are* similar, but at the same time they are actually quite different.
The Glade XML format isn't designed to be written by hand, whereas XUL is. To be honest, I'd rather have a decent UI builder....
Actually no it won't, emacs clipboard support is just wierd, probably through virtue of emacs itself being a bit wierd (note: i love emacs and practically live in it).
The trick is to realise that putting text onto the kill ring places it on PRIMARY not clipboard. In effect, selecting text then hitting M-w (or C-w) is like simply selecting text in other programs, ie you can now paste it with the middle mouse button.
This is buggy and broken, but I've yet to see somebody write a patch.
Most of the Linux clipboard problems are like this. Very popular but ultimately buggy software like Mozilla, Gaim, emacs etc which screw about with the clipboard "break" it.
Ha! Does Linux have a software mixer, you ask. Linux is much better than that! Linux has numerous software mixers!
Actually, as of kernel 2.6, ALSA is the standard which has support for userland serverless mixing via the asym and dmix plugins.
It's been maturing rapidly lately, and it now works great even with el cheapo POS cards like my on-board i810 audio chip.
dmix is really great. You just kill off all the sound servers if you have them still lying around and tell your programs to use ALSA. I expect within the next 6-12 months distros will be setting this up to work out of the box, but believe me, dmix has solved all my audio mixing problems.
However, best of all, dmix works in a way that (a) does not require userland code [which is good because it improves reliability, amongst other things], (b) does not block other sound servers [because they all have alsa backends], (c) does not prevent people with cards that do hardware mixing taking advantage of that.
One of the better solutions to the problem I've seen lately, in fact. Now the only remaining task is bugfixing basically, and getting it out to the user base.
I dunno. I needed to print something the other day, and given all the horror stories I'd read on slashdot about printing under Linux I was expecting it to be a marathon.
My setup: Fedora Core 1, I wanted to print to an HP DeskJet 580cxi (or something like that) connected to a Windows XP machine across a Windows network (ie via SMB).
I ran the much malaligned Fedora printer setup program, chose "Windows network printer" and... it didn't appear. A few minutes investigation revealed there was a bug in Fedora: I had at some point in the past enabled the personal firewall but the firewall config program was blocking Windows networking traffic.
So I switched off the firewall, went back to the printer config tool. It detected the printer correctly, gave me a HUGE list of models, I chose the closest one and read the detailed notes it fetched from the Linux Printing Database which not only gave useful info about printing from Linux, but told me a few things I didn't know about the printer itself. I was impressed, to say the least.
The wizard finished, a test page popped out of the printer in the next room, and I went and printed off my email.
There was one glitch, which I reported to bugzilla and within 3 days a patch was created by the Red Hat team.
Basically, there was only one small problem, and these sort of small problems are being squashed at a truly astonishing rate.
That's an implementation-dependent feature, not a language feature of C/C++.
Not really. To be useful, the language has to be flexible enough to let the asm code talk to stuff written in the higher-level language. How do you do that with Java/C# again?
C# very much has explicity memory allocation control. In fact, C# has similar low-level programming features to C/C++, but it packages them MUCH better.
So what? We're talking about D, not comparing C# to C++ here.
Both Java and C# have implementations that do "direct native code gen", in the sense that you can take source code and have a compiler generate shared libraries
You've clearly never attempted to actually do this. I have, with Java, and it is far from being trivial, and not all code can even be compiled in this way (typically because it depends on swing or similar libraries which make undocumented calls right into the VM).
As for C#, I have yet to see a convincing native code compiler. No, pre-JITting is not the same thing, as you still need a ton of supporting framework (and often the original DLLs for the metadata).
Both languages can be implemented without a VM, although many libraries (and many application programmers!) want the functionality that the VM provides. Where is D's VM?
What functionality is that then? D appears to have all the features I like from C# and Java (as a language) but without the obnoxious 30mb runtime download for the VM and associated tools. Why, pray tell, do I want a VM in the first place?
If he really means "templates", I'm glad that none of the other languages have them. Templates are a specific feature of C++--enormously useful, but very poorly designed. C# has parameterized types, which are less powerful but a better design.
That's wierd. I could have sworn that both Java and C# were getting generics/templates in their next versions.
Not only does C# have struct member alignment control, it has it in a way that is more explicit and better designed than what C and C++ have.
Uh, again, you seem to have misread the topic of this discussion - we're talking about D and not C#. You haven't bothered explaining why you think it's "more explicit" or "better designed" than other languages, and the same malady affects your other insights. Stating that C# is the best thing since sliced bread does not make it fact.
I wish that were true, but apt and other dependency resolvers tend to be fragile and break often, in my experience.
For instance, last time I wanted to do a dist-upgrade (or the yum equivalent), I had to dick about with config files for half an hour while I excluded packages, provided solutions and so on because apt couldn't figure out the dependency graph (it turned out to be a problem with out of date packages on the remote end).
|
The problems get infinitely worse if you start mixing repositories, which all Red Hat/Fedora/Mandrake/SuSE do because there are no repositories big enough to contain all the software you would ever want. Apt and its ilk get their knickers in a twist if you give them even slightly confused sets of metadata to work with.
Apt works great in a closed world scenario and as such is ideal for servers, corporate desktops and other setups where the software set used is small, known ahead of time and constant.
Apt does not work so great in the real world mess of the home user desktop where people want to install the latest versions of software from all over the place, on wierd new distros that their friend from down the road recommended and so on.
It's a C++ development toolkit - the users of this software are by definition developers.
I disagree, and I think it's pretty bad fanboyism that the original poster was marked "Offtopic".
A widget toolkit is used by both developers and end users.
Think about it. A developer uses the APIs, so we want them to be nice, but the user uses the widgets, so we want them to be nice too. Fully featured widgets that are designed to look good and be easy to use are just as important as nice looking APIs - in fact, I'd say they are moreso, as users typically outnumber developers by a long way.
You know, I wonder if this is a key insight. TrollTech have a big financial incentive to make a toolkit that is really nice - for developers. Most of their licensees I'd guess are developing custom apps in industry, not for mass usage by the public. Features that appeal to users therefore don't get priority, because users don't buy their software - developers do.
Maybe this is why GTK+ has been getting more user-oriented features lately like a new file picker, double-buffering, stock artwork and so on: these help the developer but not as much as they help the user.
I think TrollTech need to be careful here. If they focus only on adding developer sugar like foreach macros and (slow) XML parsers they could end up alienating users and by implication (though it may be hard to see) developers.
Actually Apple have a pretty bad record of contributing changes back.... KHTML received an enormous patch dump (at the first point that apple were legally obliged to provide it) that took many moons to integrate properly, gcc got one or two patches back but the version apple use in MacOS X is significantly different to upstream, etc. FreeBSD got some test suites and one or two trivial patches, AFAIR and I think so far XFree/X.org got nothing of value at all.
Basically Apple only contribute things back when they have to, and they often do so in a way that isn't helpful for the community (in terms of merging patches back into upstream)
Because not everybody wants to use Debian or Gentoo. Because the model in which huge numbers of people try and package every single thing in a centralised manner is inefficient and doesn't scale. How many levels does Debian have now? 4 - stable, testing, unstable and experimental, iirc.
The fact is, that it takes a lot of time to package everything like that, and a lot of human resources, which most distros simply cannot afford. Often these distros have other things which make them attractive, which is why distros like Red Hat/Fedora and SuSE are still popular.
Unfortunately Linux software distribution is not a "solved problem", as you put it, not even for Debian. Even there, in order to get up to date software you must move on to progressively more and more unstable sets of packages, which really is just not acceptable for most people.
Beyond the obvious allure, i.e., OS X is the only easy to use desktop Unix that natively supports the major productivity applications (i.e., Microsoft Office). That combination is just not available. Yea, OpenOffice is nice, but for those that *need* 100% compatibility, it's not ready for prime time. Just like linux for the desktop.
What makes you think Office for the Mac is 100% compatible with Office for Windows? Even things like different kinds of font antialiasing can be enough to break compatibility in some scenarios, let alone things like Win32 specific VBScripts (that use WSH etc). Actually, it is of course possible to use the Real Thing(tm) on Linux courtesy of CrossOver, if you need it.
Anyway, ever since NeXT opened the developer spec for OPENSTEP, GNUstep has been doing a great job of recreating a compile compatible version.
Not really - GNUstep can't read the OS X UI files for one, it's not complete, and the GNUstep team are explicitly not interested in 100% compatibility (for instance, replicating wierd/buggy semantics of Apples APIs). And of course you have the whole deal of having to redo all the artwork, nobody using the GNUstep widgets and so on....
I read that paragraph to say "other peoples computers will communicate with yours", which is, uh, kind of the point of a VoIP program. I think they are just being overly-paranoid with the legal stuff.
After tremendous testing and community feedback, the 4.4.0 Release is now available for twenty (yep that's the number 20!) popular platforms. Distros that are carrying it in with the license change integrated into their distribution are: NetBSD, Slackware Linux, Conectiva, and others. See our distro support page for the full breakout.
That's patenetly wrong and has been for about 10 years. The Windows Registry keeps track of what.dll's are installed, how many programs are using them, what version is installed, etc. I
That is not correct. The registry tracks COM component registrations. It does not record what version they are (because such things are the realm of COM), nor does it record which applications are using them. How can it, when applications are not required to make this information available to the system in a standard way (think LoadLibrary).
Those problems are a result of applications' install packages not being written correctly, not Windows missing a way to track.dll's.
On the contrary, Windows has never had good package management, which is precisely why the installers do such a bad job of things. They have no support from the OS
LSB might help here, but I havn't really seen any LSB packages in the wild...
The LSB requires all packages to use an old, crippled version of RPM and statically link anything that isn't in the LSB (ie nearly everything). That is why you don't see any on the net today.
A better solution is to have packages that can install on any distro and deal with dependencies, however this is a distinctly non-trivial thing to do. The project I've been working on for the last two years should help here, especially now we're heading straight into feature freeze. Hopefully you will see.package files available online soon, but of course that'll happen quicker if you help.
Good thing Linux provides great tools for localizing X11 apps for those custom foreign distributions
What's wrong with GNU gettext and a toolkit with strong i18n like GTK+? It's one of the best translation solutions I've seen, it certainly beats the snot out of Windows when it come to translation. No clue about MacOS/X but if you're going to attack linux for anything, i18n should not be it.
A: It is based on an OpenStep, a open specification that has been around for quite a while, as has GNUStep, a open source implementation of that spec. In addition, Apple has in the past prototyped it's own "yellowbox" version of Cocoa running on top of Windows.
You're smoking crack if you think that GNUStep is some kind of portability layer for Cocoa. Last time I checked, the GNUStep folks hadn't even bothered reverse engineering the NIB format, instead choosing to use their own.
GNUStep is something that bares a vague resemblence to NeXTStep - it is in no way, shape, or form something useful for porting Cocoa apps let alone running the binaries direct Wine style.
Slashdot Mirror
You can already "embed" XUL in IE of course, by having the user download the Gecko ActiveX control and effectively embed a renderer within a renderer, but that's a cheap hack and has severe performance implications.
To be frank, I'm 100% not convinced that Avalon is going to be as world changing as Miggy predicts. I think it's especially rash to be starting internal projects even if they are "thought only" to develop a competitor.
Miguel thinks Avalon will be great, because it will let you deploy applications via the web browser that use native widgets, and be nicely integrated with .NET and so on.
But ... but ... but ... Microsoft did this years ago (minus .net). Or am I really the only one who remembers the version of Outlook implemented entirely using DHTML/HTA (which produces native widgets). I can't remember the codename, but the project was scrapped. The benefits of running Outlook inside IE just were not compelling enough to overcome the performance and other problems.
I'm not denying it'd be useful. The long term UI goals for my own packaging/installer project are that the user should be able to launch (and implicitly install) software simply by clicking on an icon embedded in a web page. As far as the user is concerned then the effects would be the same, so the real differences lie in how the developer sees things.
In the Avalon world view, the developer creates widgets on a canvas (AFAIK), ties them together with .NET code, and then .NET CAS allows you to launch it from a web browser without fear of it doing nasty things to your machine (which is a massive oversimplification, but oh well).
In fact, we can do this sort of thing today, with technologies that are either here or just around the corner. SELinux allows you to effectively sandbox native code to a fine degree, similar to .NET CAS except enforced at the kernel level and not by a VM. It's not just a set of kernel security checks - it's actually a security architecture with an exposed set of APIs which allow people to use MAC security features to a high level.
I don't know enough about .NET security to know how it compares, but SELinux policy is easily distributable in the form of text files and allows you use native code, which runs directly on the CPU without the overhead of a VM and huge set of managed APIs.
So, if you can download some native code and correctly sandbox it, you have the start of web app deployment. XAML appears to bear a superficial representation to Glade (note: NOT xul) but using a more customised and therefore human friendly schema.
I say Glade and not XUL because a Glade file is, in actuality, not an UI description at all. It's really a persisted GObject tree that libglade uses along with the GObject reflection APIs to reconstruct the GUI at runtime. I have read that XAML despite appearances is similar: it is a persisted .NET object graph.
So, I think if Miguel starts from "what user experiences does this technology allow" and work backwards, he'll find we already have the basics in production. Sure, they need to be improved and tied together, but they are there nonetheless.
Finally I think it's wrong to say that the reason desktop Linux didn't happen in 1994 was because people were "sleeping at the wheel". The fact of the matter was in 1994 Microsoft already had several thousand people working on Windows full time, whereas desktop Linux had .... none.
Really, I think a simpler explanation is just that MS had a monopoly pumping cash into their development teams, and Linux did not. Its falling behind was therefore completely inevitable until it gained enough momentum to move as fast as Microsoft do.
It's like saying hitting reset is a good way to log out, It's not.
WiX didn't cost Microsoft anything anyway, it was written in the authors spare time according to the original announcement and blog entries.
Wow, I don't think I've ever seen anybody say that. You must have used some truly appallingly bad APIs.
Win32 is easily one of the worst APIs in the world, bar none. In what other API do you have a function like this:
BOOL InitCommonControlsEx( LPINITCOMMONCONTROLSEX lpInitCtrls );
Now I ask you. Why is it better to use a structure that has to be allocated and initialized for passing a parameter than simply introducing a new function in the (unlikely) case that new parameters need to be added?
Here's another example. Anybody who can guess what the RpcUseProtSeqEpExA function does, have a cookie. It's actually short for "Remote Procedure Call Use Protocol Sequence with Endpoint, Extended ANSI version".
I've yet to encounter any C API with more bizarre quirks than Win32. Whether it's typedeffing int to INT, inserting random reserved (must be 0) arguments into the middle of functions, inventing yet another set of error codes (like ERROR_SUCCESS :) or just generally being buggy and sucking, Win32 is a textbook example of how not to design an API.
If you want to see a good C API, take a look at GTK+.
By legislating that all companies must conform to minimum standards, this problem is removed.
That's less effective these days of course as corporates are more mobile across national boundaries, and the legal system hasn't really caught up yet. However the principle is sound and more to the point has a lot of prior art which indicates it works.
Wow, those two posts of yours really changed my mind on the war. Up until now I really wasn't sure whether it was a good idea or not, but this is one of the most clear and insightful analyses I've seen - certainly moreso than in popular media (newspapers, tv, etc). thanks!
That's what you think. In actuality you thought you were buying the ability to write letters and create spreadsheets, but you were actually buying the ability to write DOC and XLS files, which is a different matter entirely.
Let me ask you - was the task or service you were willing to pay for using a computer, or using Windows? The two are often commingled but are actually different.
Depends on the job, and how you sell things. If you're selling second hand cars and you move to another state to sell them for a better salary, most people would not consider you lacking in integrity.
What we have here is different - only somebody incredibly naive would think that this guy made the sale of SuSE without once trashing or mentioning the bad points of Windows: seeing as how they are the closest competition and all. In fact, I wouldn't be at all surprised if that was the main selling point: Linux is better than Windows because (a) (b) (c).
Now the guy is going to be telling people the exact opposite. In other words, at one or other of the jobs (most likely both) the guy will have been flat out lying.
To be frank, I don't give a toss that the guy is in sales. There's right and then there's wrong, and if you are are lying through your teeth to make a sale you're still a lier. If you are influencing huge, important decisions people make on the basis of things you don't believe yourself .... well, in my world view you have no integrity and your job position does not excuse that.
I'm not saying this guy has no integrity! I don't know what his sales technique is like. It's possible all he did was point out how great SuSE Linux is, and how it'd meet their needs better and didn't mention Microsoft once. It's possible, but unlikely.
In other words, ad hominem attacks lack honour and integrity - and by the way bonch, that holds true whether you're attacking products, people or places.
It's a persisted GObject tree. libglade reads the XML which maps pretty much directly to constructing a tree of GObjects and setting their properties and signals. The reason it looks like XML describing XML is because it's describing a tree of attributed nodes, but with callbacks - ie they *are* similar, but at the same time they are actually quite different.
The Glade XML format isn't designed to be written by hand, whereas XUL is. To be honest, I'd rather have a decent UI builder....
The trick is to realise that putting text onto the kill ring places it on PRIMARY not clipboard. In effect, selecting text then hitting M-w (or C-w) is like simply selecting text in other programs, ie you can now paste it with the middle mouse button.
This is buggy and broken, but I've yet to see somebody write a patch.
Most of the Linux clipboard problems are like this. Very popular but ultimately buggy software like Mozilla, Gaim, emacs etc which screw about with the clipboard "break" it.
Actually, as of kernel 2.6, ALSA is the standard which has support for userland serverless mixing via the asym and dmix plugins.
It's been maturing rapidly lately, and it now works great even with el cheapo POS cards like my on-board i810 audio chip.
dmix is really great. You just kill off all the sound servers if you have them still lying around and tell your programs to use ALSA. I expect within the next 6-12 months distros will be setting this up to work out of the box, but believe me, dmix has solved all my audio mixing problems.
However, best of all, dmix works in a way that (a) does not require userland code [which is good because it improves reliability, amongst other things], (b) does not block other sound servers [because they all have alsa backends], (c) does not prevent people with cards that do hardware mixing taking advantage of that.
One of the better solutions to the problem I've seen lately, in fact. Now the only remaining task is bugfixing basically, and getting it out to the user base.
My setup: Fedora Core 1, I wanted to print to an HP DeskJet 580cxi (or something like that) connected to a Windows XP machine across a Windows network (ie via SMB).
I ran the much malaligned Fedora printer setup program, chose "Windows network printer" and ... it didn't appear. A few minutes investigation revealed there was a bug in Fedora: I had at some point in the past enabled the personal firewall but the firewall config program was blocking Windows networking traffic.
So I switched off the firewall, went back to the printer config tool. It detected the printer correctly, gave me a HUGE list of models, I chose the closest one and read the detailed notes it fetched from the Linux Printing Database which not only gave useful info about printing from Linux, but told me a few things I didn't know about the printer itself. I was impressed, to say the least.
The wizard finished, a test page popped out of the printer in the next room, and I went and printed off my email.
There was one glitch, which I reported to bugzilla and within 3 days a patch was created by the Red Hat team.
Basically, there was only one small problem, and these sort of small problems are being squashed at a truly astonishing rate.
Not really. To be useful, the language has to be flexible enough to let the asm code talk to stuff written in the higher-level language. How do you do that with Java/C# again?
C# very much has explicity memory allocation control. In fact, C# has similar low-level programming features to C/C++, but it packages them MUCH better.
So what? We're talking about D, not comparing C# to C++ here.
Both Java and C# have implementations that do "direct native code gen", in the sense that you can take source code and have a compiler generate shared libraries
You've clearly never attempted to actually do this. I have, with Java, and it is far from being trivial, and not all code can even be compiled in this way (typically because it depends on swing or similar libraries which make undocumented calls right into the VM).
As for C#, I have yet to see a convincing native code compiler. No, pre-JITting is not the same thing, as you still need a ton of supporting framework (and often the original DLLs for the metadata).
Both languages can be implemented without a VM, although many libraries (and many application programmers!) want the functionality that the VM provides. Where is D's VM?
What functionality is that then? D appears to have all the features I like from C# and Java (as a language) but without the obnoxious 30mb runtime download for the VM and associated tools. Why, pray tell, do I want a VM in the first place?
If he really means "templates", I'm glad that none of the other languages have them. Templates are a specific feature of C++--enormously useful, but very poorly designed. C# has parameterized types, which are less powerful but a better design.
That's wierd. I could have sworn that both Java and C# were getting generics/templates in their next versions.
Not only does C# have struct member alignment control, it has it in a way that is more explicit and better designed than what C and C++ have.
Uh, again, you seem to have misread the topic of this discussion - we're talking about D and not C#. You haven't bothered explaining why you think it's "more explicit" or "better designed" than other languages, and the same malady affects your other insights. Stating that C# is the best thing since sliced bread does not make it fact.
For instance, last time I wanted to do a dist-upgrade (or the yum equivalent), I had to dick about with config files for half an hour while I excluded packages, provided solutions and so on because apt couldn't figure out the dependency graph (it turned out to be a problem with out of date packages on the remote end) .
| The problems get infinitely worse if you start mixing repositories, which all Red Hat/Fedora/Mandrake/SuSE do because there are no repositories big enough to contain all the software you would ever want. Apt and its ilk get their knickers in a twist if you give them even slightly confused sets of metadata to work with.
Apt works great in a closed world scenario and as such is ideal for servers, corporate desktops and other setups where the software set used is small, known ahead of time and constant.
Apt does not work so great in the real world mess of the home user desktop where people want to install the latest versions of software from all over the place, on wierd new distros that their friend from down the road recommended and so on.
I disagree, and I think it's pretty bad fanboyism that the original poster was marked "Offtopic".
A widget toolkit is used by both developers and end users.
Think about it. A developer uses the APIs, so we want them to be nice, but the user uses the widgets, so we want them to be nice too. Fully featured widgets that are designed to look good and be easy to use are just as important as nice looking APIs - in fact, I'd say they are moreso, as users typically outnumber developers by a long way.
You know, I wonder if this is a key insight. TrollTech have a big financial incentive to make a toolkit that is really nice - for developers. Most of their licensees I'd guess are developing custom apps in industry, not for mass usage by the public. Features that appeal to users therefore don't get priority, because users don't buy their software - developers do.
Maybe this is why GTK+ has been getting more user-oriented features lately like a new file picker, double-buffering, stock artwork and so on: these help the developer but not as much as they help the user.
I think TrollTech need to be careful here. If they focus only on adding developer sugar like foreach macros and (slow) XML parsers they could end up alienating users and by implication (though it may be hard to see) developers.
Actually Apple have a pretty bad record of contributing changes back .... KHTML received an enormous patch dump (at the first point that apple were legally obliged to provide it) that took many moons to integrate properly, gcc got one or two patches back but the version apple use in MacOS X is significantly different to upstream, etc. FreeBSD got some test suites and one or two trivial patches, AFAIR and I think so far XFree/X.org got nothing of value at all.
Basically Apple only contribute things back when they have to, and they often do so in a way that isn't helpful for the community (in terms of merging patches back into upstream)
The fact is, that it takes a lot of time to package everything like that, and a lot of human resources, which most distros simply cannot afford. Often these distros have other things which make them attractive, which is why distros like Red Hat/Fedora and SuSE are still popular.
Unfortunately Linux software distribution is not a "solved problem", as you put it, not even for Debian. Even there, in order to get up to date software you must move on to progressively more and more unstable sets of packages, which really is just not acceptable for most people.
If Apple is advertising with Gator anywhere, that says a lot about their advertising policy (or lack of one).
What makes you think Office for the Mac is 100% compatible with Office for Windows? Even things like different kinds of font antialiasing can be enough to break compatibility in some scenarios, let alone things like Win32 specific VBScripts (that use WSH etc). Actually, it is of course possible to use the Real Thing(tm) on Linux courtesy of CrossOver, if you need it.
Anyway, ever since NeXT opened the developer spec for OPENSTEP, GNUstep has been doing a great job of recreating a compile compatible version.
Not really - GNUstep can't read the OS X UI files for one, it's not complete, and the GNUstep team are explicitly not interested in 100% compatibility (for instance, replicating wierd/buggy semantics of Apples APIs). And of course you have the whole deal of having to redo all the artwork, nobody using the GNUstep widgets and so on ....
I read that paragraph to say "other peoples computers will communicate with yours", which is, uh, kind of the point of a VoIP program. I think they are just being overly-paranoid with the legal stuff.
They also have an "interview" with David Dawes about the license change.
That is not correct. The registry tracks COM component registrations. It does not record what version they are (because such things are the realm of COM), nor does it record which applications are using them. How can it, when applications are not required to make this information available to the system in a standard way (think LoadLibrary).
Those problems are a result of applications' install packages not being written correctly, not Windows missing a way to track .dll's.
On the contrary, Windows has never had good package management, which is precisely why the installers do such a bad job of things. They have no support from the OS
The LSB requires all packages to use an old, crippled version of RPM and statically link anything that isn't in the LSB (ie nearly everything). That is why you don't see any on the net today.
A better solution is to have packages that can install on any distro and deal with dependencies, however this is a distinctly non-trivial thing to do. The project I've been working on for the last two years should help here, especially now we're heading straight into feature freeze. Hopefully you will see .package files available online soon, but of course that'll happen quicker if you help.
What's wrong with GNU gettext and a toolkit with strong i18n like GTK+? It's one of the best translation solutions I've seen, it certainly beats the snot out of Windows when it come to translation. No clue about MacOS/X but if you're going to attack linux for anything, i18n should not be it.
You're smoking crack if you think that GNUStep is some kind of portability layer for Cocoa. Last time I checked, the GNUStep folks hadn't even bothered reverse engineering the NIB format, instead choosing to use their own.
GNUStep is something that bares a vague resemblence to NeXTStep - it is in no way, shape, or form something useful for porting Cocoa apps let alone running the binaries direct Wine style.