Oh, I missed that. Thanks! That's good news. SWT on GTK is already very nice but I'm sure there's value in a Qt port as well. Actually, you could just have SWT on Jambi which gives you the Java bindings for free.
Welcome to the dreadful hack that is the Windows graphics overlay system. It allocates a very specific color that will be treated as a video area by the video card, so that it won't overlap windows that should be on top. It's clever, but XVideo in the open source world is much better. As usual.
Let's cut Linux a break, the development community has managed to maintain a "stable" branch stable enough to fork several enterprise releases, while allowing a pace of development that would normally only happen in bleeding edge branches and require a year-long stability cycle.
Linux is so far the only major project to pull this off and make it shine. Watching this work and seeing the impact on my computing power has made me a Linux Believer after spending a pretty long time as a BSD Bigot.
This is a noble goal, and I support a unification on top of Qt4, but it's just not going to happen as long as Qt4 is GPL. GNOME deliberately uses the LGPL to allow free proprietary development (think VMWare, or even just GPL-incompatible like SWT/Eclipse).
If GTK was abandoned, a lot of projects would have to change their license or fork the toolkit. A *lot* of the software we use is GPL incompatible. That doesn't make it non-free, it's just the way the licenses work. For me the biggest hit would be Eclipse, which is based on SWT, which can legally derive from GTK but not Qt.
But what you said still doesn't make sense. You said the recipient of the *code* in each case, which makes the BSDL recipient more free, because he already has the source (plenty of freedom) but none of the GPL redistribution restrictions. If you'd said resulting binary, instead of code, sure.
Wait, what? Isn't that completely backwards? GPL limits redistribution of aggregated and derivative works, which are things that a recipient would be doing.
Regards to sig: What problem are you having with plain old text? I've been using plain old text mode for years, and it was perfectly preserved even in this latest Slashdot. Check that it's set properly in Options and maybe double-check it in your user options as well.
I think what people really forget about the GPL is that it has a unique potential for dual licensing. Trolltech use this extremely well with Qt.
If you want to write a non-free application based on Qt, you need to purchase a commercial license. Presumably you're making money off your application, so the cost of a Qt license is a perfectly acceptable cost. And if you're just writing a nice open source application, in one of Qt's accepted open source licenses (including, yes, BSDL), you're totally welcome to use the GPL Qt.
It ensures the developing company gets a slice of the money made off their product, while leaving the code open and free for use in free software. It's a very solid model and it's done wonders for Qt so far, even while GTK+ is LGPL and 100% free for commercial use, just because the Qt technological offering is strong enough to excuse the tougher license.
Best of all, even if you use assert() (or similar) for really explicit bounds checking, GCC will omit it from code paths where it's deemed to be unused. So if your accesses are being inlined (and if they're not, take a long hard look at your life) then the already-safe paths won't have the check overhead even in a debug build.
Ah, but it would be written as a J2EE application. And the input wouldn't be.y, it'd be an XML document. And the output wouldn't be C, it'd be another XML, passing through a terabyte of XSLT. Then you pass this compiled parser XML, only a gigabyte in size, and your language file to a parser web service and it returns even more XML representing the parse tree.
Who cares? Like GCC versus TinyCC, being bloated means it can produce a more useful output. GNUware can be faulted for being heavy compared to traditional Unix tools, but the functionality and flexibility provided more than makes up for it.
Except for autotools. What the HELL were they thinking.
I agree, even though I am very handy with vim, I wouldn't use it for a large project in, say, Java when I could use Eclipse instead. Eclipse has much much more advanced features and it really "gets" how Java projects are developed. I still write build and distribution gantries even for Eclipse projects, just to maximise automation and control for the products themselves. And sure, I'll write those gantries with vim, just like most short scripts.
Linux runs on more platforms with more features and higher performance than *ANY* other operating system kernel. While some specialised operating systems can perform slightly better on their most native architecture, the difference is nowhere near enough to make up for the lack of functionality compared to a modern Linux distribution.
Linux gets this power specifically from being able to break API stability at any time. If an architectural improvement can be made, it'll be made, even if every driver has to be modified. And this has been done over and over. That's why Linux scales to thousands of CPUs in a single node, on CPU architectures Windows has never even booted on natively. This flexibility and power keeps Linux dominating markets Windows and MacOSX can't even enter.
You have to look at this from the perspective of a few years from now. Linux hardware support is already a very good situation, and it can only get better. At worst we'll still have a binary driver or two per desktop, at best we'll have most desktops working completely out of the box with open source drivers. And the usability and functionality improvements just stack on.
The one thing that still kills Linux more than anything is being unable to run proprietary applications like, say, Photoshop *natively*. That's something the next Windows will have to face as well, because it can't run them natively, and even a good emulation is still an emulation. And who knows, by then, maybe companies will already be shipping Linux versions because they know Windows is dead.
Which do you think your typical ISV will favor, an open, standardised platform with hundreds of millions of installs, multiple enterprise support vendors, and over a decade of maturity, or a brand new proprietary operating system with at best an emulation of a non-standard API with no formal definition and only one support vendor?
Microsoft got lucky by getting early penetration in developing technology markets. It won't work the same next time. Now the playing field is levelling and Windows has nowhere to go but down.
I've said it half a dozen times in this post tree already. Emulation would require just as much mass as the original system, and with most non-trivial Windows applications hooking into the kernel, services, DLLs via injection, COM, ActiveX, etc. you'd need all of the same legacy bloat. So you'd still be using a full version of Windows in addition to your light and clean operating system, so the end result is overall more bloated and buggy.
Sure, except any non-trivial.NET application uses COM and services and native APIs that all tie the code back to Windows. Many even have kernel helpers. So a Windows alternative that aims to support non-trivial Windows applications, even.NET ones, will have to support those same systems.
That's what permanently prevents Windows from being trimmed down. Making it modular doesn't help because you'll need almost all of the modules to run a regular system anyway, so you have all of the same code plus all the extra overhead of the modularity.
And yes, technically Linux has the same backwards compatibility problem, but the flexibility and vitality of open source projects has prevented this from being a serious problem in practice. So while Windows still has numerous per-application hacks specifically for backwards compatibility, open source distributors and maintainers simply fix the bugs and rebase on new APIs.
An example is that almost nobody uses GTK 1.x any more, even though only a few years ago about half of all graphical applications did. On Windows most programs still use the Win32 GUI API, over 13 years old already, either directly or through the thin indirection of MFC. Things just don't get revamped in the Windows ecosystem much, so all of that backwards compatibility has to stay.
When Microsoft takes this step in a few years, OSX will already have been around over 10 years and Linux much longer. And both of them have healthy software ecosystems, a huge part of maturity. Linux has SEVERAL distributions each providing commercial long-term support for specific versions, which is a vastly more mature support space than any other operating system has ever had. Microsoft's support for Windows has been a joke, giving higher priority to DRM patches than security patches.
I said this in a post above and I'll paste it here too: "but with almost every non-trivial Windows application hooking itself into the kernel and services and everywhere, that will NOT work for most of what ties people to Windows anyway"
No, that is ridiculous. MacOSX kept a lot of compatibility with its BSD base and emulated MacOS9. The transition period was huge, and it was starting from scratch. Microsoft will not have the same opportunity, and it will lose a lot of market share.
The best Microsoft could do is something similar, rebasing on BSD and making a compatibility layer, but with almost every non-trivial Windows application hooking itself into the kernel and services and everywhere, that will NOT work for most of what ties people to Windows anyway.
All of which still tie you to Windows. What are you going to do, run Microsoft Ubersystem as a pure RDP client to Windows XP, which will be unsupported by then? Let's face it - as soon as you're not compatible with Windows, you may as well run Linux anyway, and Microsoft knows that very well.
WINE is the most mature Windows compatibility layer there is, and the best Microsoft could do is contribute to it, which you know very well they won't. At that point they may as well make their own Linux distribution or pull an Apple and rebase on BSD. They're totally screwed. The Windows upgrade model is not sustainable and Windows 7 will prove it even more clearly than Vista did.
They're boned as far as operating systems go. They can't break backwards compatibility, but that same backwards compatibility is killing them as they try to improve the system.
Think about it - if you're making a clean break from Windows, would you choose a mature, well established alternative like Linux or MacOSX, or would you choose a completely new, unproven and completely incompatible and unstandardised operating system from Microsoft? Even if the new Microsoft OS is cleaner, being incompatible with EVERY operating system out there would absolutely kill it.
So they can't keep going with the Windows they have, and they can't start over without losing the only asset Windows has, its backwards compatibility. The superior technology of Linux and MacOSX will keep them alive long after Windows' architecture crumbles, and Vista is the first huge sign that's happening.
The drop dead obvious confirmation of this is that Windows 7 was meant to be modularised and cleaned up, and all of that has been cancelled already.
Push to get your wireless driver into mainline or at least the Ubuntu modules package, so it will be re-integrated and distributed when new kernel versions are. All of my devices, including proprietary video drivers and wireless cards, are supported in Ubuntu's official packages because other thoughtful people already did this. I never have to compile, let alone recompile.
Slashdot Mirror
Oh, I missed that. Thanks! That's good news. SWT on GTK is already very nice but I'm sure there's value in a Qt port as well. Actually, you could just have SWT on Jambi which gives you the Java bindings for free.
Welcome to the dreadful hack that is the Windows graphics overlay system. It allocates a very specific color that will be treated as a video area by the video card, so that it won't overlap windows that should be on top. It's clever, but XVideo in the open source world is much better. As usual.
Let's cut Linux a break, the development community has managed to maintain a "stable" branch stable enough to fork several enterprise releases, while allowing a pace of development that would normally only happen in bleeding edge branches and require a year-long stability cycle.
Linux is so far the only major project to pull this off and make it shine. Watching this work and seeing the impact on my computing power has made me a Linux Believer after spending a pretty long time as a BSD Bigot.
This is a noble goal, and I support a unification on top of Qt4, but it's just not going to happen as long as Qt4 is GPL. GNOME deliberately uses the LGPL to allow free proprietary development (think VMWare, or even just GPL-incompatible like SWT/Eclipse).
If GTK was abandoned, a lot of projects would have to change their license or fork the toolkit. A *lot* of the software we use is GPL incompatible. That doesn't make it non-free, it's just the way the licenses work. For me the biggest hit would be Eclipse, which is based on SWT, which can legally derive from GTK but not Qt.
But what you said still doesn't make sense. You said the recipient of the *code* in each case, which makes the BSDL recipient more free, because he already has the source (plenty of freedom) but none of the GPL redistribution restrictions. If you'd said resulting binary, instead of code, sure.
Wait, what? Isn't that completely backwards? GPL limits redistribution of aggregated and derivative works, which are things that a recipient would be doing.
Regards to sig: What problem are you having with plain old text? I've been using plain old text mode for years, and it was perfectly preserved even in this latest Slashdot. Check that it's set properly in Options and maybe double-check it in your user options as well.
I think what people really forget about the GPL is that it has a unique potential for dual licensing. Trolltech use this extremely well with Qt.
If you want to write a non-free application based on Qt, you need to purchase a commercial license. Presumably you're making money off your application, so the cost of a Qt license is a perfectly acceptable cost. And if you're just writing a nice open source application, in one of Qt's accepted open source licenses (including, yes, BSDL), you're totally welcome to use the GPL Qt.
It ensures the developing company gets a slice of the money made off their product, while leaving the code open and free for use in free software. It's a very solid model and it's done wonders for Qt so far, even while GTK+ is LGPL and 100% free for commercial use, just because the Qt technological offering is strong enough to excuse the tougher license.
Sorry that ^U I am Spartacus.
Best of all, even if you use assert() (or similar) for really explicit bounds checking, GCC will omit it from code paths where it's deemed to be unused. So if your accesses are being inlined (and if they're not, take a long hard look at your life) then the already-safe paths won't have the check overhead even in a debug build.
Yes, I've tested it. Yes, it's impressive.
Ah, but it would be written as a J2EE application. And the input wouldn't be .y, it'd be an XML document. And the output wouldn't be C, it'd be another XML, passing through a terabyte of XSLT. Then you pass this compiled parser XML, only a gigabyte in size, and your language file to a parser web service and it returns even more XML representing the parse tree.
Ahh, progress.
Who cares? Like GCC versus TinyCC, being bloated means it can produce a more useful output. GNUware can be faulted for being heavy compared to traditional Unix tools, but the functionality and flexibility provided more than makes up for it.
Except for autotools. What the HELL were they thinking.
I agree, even though I am very handy with vim, I wouldn't use it for a large project in, say, Java when I could use Eclipse instead. Eclipse has much much more advanced features and it really "gets" how Java projects are developed. I still write build and distribution gantries even for Eclipse projects, just to maximise automation and control for the products themselves. And sure, I'll write those gantries with vim, just like most short scripts.
Right, NOW. But it can't continue, and even Microsoft is admitting that. That's what we're talking about. Try to keep up.
Linux runs on more platforms with more features and higher performance than *ANY* other operating system kernel. While some specialised operating systems can perform slightly better on their most native architecture, the difference is nowhere near enough to make up for the lack of functionality compared to a modern Linux distribution.
Linux gets this power specifically from being able to break API stability at any time. If an architectural improvement can be made, it'll be made, even if every driver has to be modified. And this has been done over and over. That's why Linux scales to thousands of CPUs in a single node, on CPU architectures Windows has never even booted on natively. This flexibility and power keeps Linux dominating markets Windows and MacOSX can't even enter.
You have to look at this from the perspective of a few years from now. Linux hardware support is already a very good situation, and it can only get better. At worst we'll still have a binary driver or two per desktop, at best we'll have most desktops working completely out of the box with open source drivers. And the usability and functionality improvements just stack on.
The one thing that still kills Linux more than anything is being unable to run proprietary applications like, say, Photoshop *natively*. That's something the next Windows will have to face as well, because it can't run them natively, and even a good emulation is still an emulation. And who knows, by then, maybe companies will already be shipping Linux versions because they know Windows is dead.
Which do you think your typical ISV will favor, an open, standardised platform with hundreds of millions of installs, multiple enterprise support vendors, and over a decade of maturity, or a brand new proprietary operating system with at best an emulation of a non-standard API with no formal definition and only one support vendor?
Microsoft got lucky by getting early penetration in developing technology markets. It won't work the same next time. Now the playing field is levelling and Windows has nowhere to go but down.
I've said it half a dozen times in this post tree already. Emulation would require just as much mass as the original system, and with most non-trivial Windows applications hooking into the kernel, services, DLLs via injection, COM, ActiveX, etc. you'd need all of the same legacy bloat. So you'd still be using a full version of Windows in addition to your light and clean operating system, so the end result is overall more bloated and buggy.
Sure, except any non-trivial .NET application uses COM and services and native APIs that all tie the code back to Windows. Many even have kernel helpers. So a Windows alternative that aims to support non-trivial Windows applications, even .NET ones, will have to support those same systems.
That's what permanently prevents Windows from being trimmed down. Making it modular doesn't help because you'll need almost all of the modules to run a regular system anyway, so you have all of the same code plus all the extra overhead of the modularity.
And yes, technically Linux has the same backwards compatibility problem, but the flexibility and vitality of open source projects has prevented this from being a serious problem in practice. So while Windows still has numerous per-application hacks specifically for backwards compatibility, open source distributors and maintainers simply fix the bugs and rebase on new APIs.
An example is that almost nobody uses GTK 1.x any more, even though only a few years ago about half of all graphical applications did. On Windows most programs still use the Win32 GUI API, over 13 years old already, either directly or through the thin indirection of MFC. Things just don't get revamped in the Windows ecosystem much, so all of that backwards compatibility has to stay.
When Microsoft takes this step in a few years, OSX will already have been around over 10 years and Linux much longer. And both of them have healthy software ecosystems, a huge part of maturity. Linux has SEVERAL distributions each providing commercial long-term support for specific versions, which is a vastly more mature support space than any other operating system has ever had. Microsoft's support for Windows has been a joke, giving higher priority to DRM patches than security patches.
I said this in a post above and I'll paste it here too: "but with almost every non-trivial Windows application hooking itself into the kernel and services and everywhere, that will NOT work for most of what ties people to Windows anyway"
No, that is ridiculous. MacOSX kept a lot of compatibility with its BSD base and emulated MacOS9. The transition period was huge, and it was starting from scratch. Microsoft will not have the same opportunity, and it will lose a lot of market share.
The best Microsoft could do is something similar, rebasing on BSD and making a compatibility layer, but with almost every non-trivial Windows application hooking itself into the kernel and services and everywhere, that will NOT work for most of what ties people to Windows anyway.
All of which still tie you to Windows. What are you going to do, run Microsoft Ubersystem as a pure RDP client to Windows XP, which will be unsupported by then? Let's face it - as soon as you're not compatible with Windows, you may as well run Linux anyway, and Microsoft knows that very well.
WINE is the most mature Windows compatibility layer there is, and the best Microsoft could do is contribute to it, which you know very well they won't. At that point they may as well make their own Linux distribution or pull an Apple and rebase on BSD. They're totally screwed. The Windows upgrade model is not sustainable and Windows 7 will prove it even more clearly than Vista did.
They're boned as far as operating systems go. They can't break backwards compatibility, but that same backwards compatibility is killing them as they try to improve the system.
Think about it - if you're making a clean break from Windows, would you choose a mature, well established alternative like Linux or MacOSX, or would you choose a completely new, unproven and completely incompatible and unstandardised operating system from Microsoft? Even if the new Microsoft OS is cleaner, being incompatible with EVERY operating system out there would absolutely kill it.
So they can't keep going with the Windows they have, and they can't start over without losing the only asset Windows has, its backwards compatibility. The superior technology of Linux and MacOSX will keep them alive long after Windows' architecture crumbles, and Vista is the first huge sign that's happening.
The drop dead obvious confirmation of this is that Windows 7 was meant to be modularised and cleaned up, and all of that has been cancelled already.
Push to get your wireless driver into mainline or at least the Ubuntu modules package, so it will be re-integrated and distributed when new kernel versions are. All of my devices, including proprietary video drivers and wireless cards, are supported in Ubuntu's official packages because other thoughtful people already did this. I never have to compile, let alone recompile.